> > 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.