mirror of
https://github.com/winfsp/winfsp.git
synced 2026-06-26 06:18:21 -05:00
yeonsh
82f59837f6
Under heavy concurrent rename + change-notification load a volume can deadlock permanently: all renames (exclusive) and opens (shared) on the volume block, freezing the mount. FspFileSystemNotifyBegin (FspVolumeNotifyLock) acquires the per-volume FileRenameResource shared via an owner pointer (&VolumeNotifyCount) and holds it for the whole Begin/End session. If a rename queues as an exclusive waiter mid-session, the asynchronous FspVolumeNotifyWork then re-acquires the same resource shared with ExAcquireResourceSharedLite. Due to ERESOURCE writer-priority that shared acquire blocks behind the queued exclusive waiter (the worker thread is not the owner -- the owner is the &VolumeNotifyCount pointer). But that work item is the one that must process FspFileSystemNotifyEnd to drop VolumeNotifyCount to 0 and release the session, so it can never run: the session lock is never released and the rename waits forever, while VolumeNotifyCount runs away as Begin keeps incrementing it. Acquire the rename resource in FspVolumeNotifyWork with ExAcquireSharedStarveExclusive instead. The enclosing Begin/End session already holds the resource shared and already defers renames until End, so granting this redundant shared acquire ahead of the queued exclusive waiter preserves name-stability semantics while breaking the deadlock. A real exclusive holder still blocks the starve-exclusive acquire, so correctness is unchanged.