The shared lock wait loop on line 88 had a parenthesization bug that
caused the `|| entry.activeExclusiveLockOwnerCount > 0` check to fall
outside the `!lock.isDeleted` guard. Due to Go operator precedence
(&& binds tighter than ||), the condition evaluated as:
(!lock.isDeleted && (waiters_check)) || exclusiveCount > 0
This meant a deleted (cancelled) shared lock waiter could never exit
the wait loop while any exclusive lock was active on the same key,
since the isDeleted check was bypassed. The goroutine would spin in
cond.Wait() forever, leaking and potentially cascading to block other
FUSE operations on the same file handle.
The fix adds parentheses to match the exclusive lock condition on
line 84, so isDeleted properly gates the entire wait expression:
!lock.isDeleted && ((waiters_check) || exclusiveCount > 0)
This bug has existed since commit c43238b30 ("fix waiting condition")
but became more likely to trigger in recent versions due to increased
lock contention from parallel chunk fetching (#7569), directory handle
mutex (#7674), and metadata cache snapshot consistency (#8531).
Fixes#8696
Copilot