On Mon, Nov 24, 2025 at 06:05:52PM +0000, Tim Leslie wrote:
> > > There is no intended semantic change beyond avoiding an extra mutex acquisition around what is already documented as a racy snapshot in both call sites.
> > 
> > 
> > If the check is done without the mutex, what will ensure proper
> > ordering when there is a concurrent close/dup call?
> 
> The check isn’t trying to order itself against close/dup; it’s just a best‑effort snapshot of whether fd still points at the same fp we looked up earlier. As long as the close/dup side updates fd_ofiles[fd] with a single coherent store, a plain READ_ONCE(fdp->fd_ofiles[fd]) != fp is enough: if close/dup ran first we see a different pointer and take the “lost the race, close already tore the lock down” path, and if they run later they’ll still do the real VOP_ADVLOCK(F_UNLCK) / close‑side cleanup. kern_event is doing the same style of equality check for FILTEROP_ISFD knotes, so we’re keeping that pattern, and the actual ordering for advisory locks vs close still comes from fdplock around the fd‑table mutation and from the vnode/lockf side, not from this extra mutex around a pointer compare.

The mutex ensures that fd_checkclosed() sees the latest state. It makes
the code easier to understand by serializing the check with updates.

I would rather not remove the lock because I am hesitant to assume
that a plain read operation always behaves in a "synchronous" way
on all the supported architectures.