Public/winfsp
1
0
Fork 0
mirror of https://github.com/winfsp/winfsp.git synced 2026-06-26 06:18:21 -05:00
Code Activity

sys: fix FileRenameResource self-deadlock between notify session and FspVolumeNotifyWork

Browse Source 
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.
This commit is contained in:
yeonsh
2026-06-05 22:48:47 +09:00
parent ff9e38c82d
commit 82f59837f6
2 changed files with 27 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/sys/volume.c
+9 -1
View File
@@ -1499,7 +1499,15 @@ static VOID FspVolumeNotifyWork(PVOID NotifyWorkItem0)
BOOLEAN Unlock = FALSE;
NTSTATUS Result;
FspFsvolDeviceFileRenameAcquireShared(FsvolDeviceObject);
/*
* Starve queued exclusive (rename) waiters here to avoid a self-deadlock:
* the enclosing FspFileSystemNotifyBegin/End session already holds this
* resource shared, and a rename that queues exclusive mid-session would
* otherwise block this work item -- the same work item that must release
* the session (FspVolumeNotifyLock count) and unblock that rename. See
* FspFsvolDeviceFileRenameAcquireSharedStarveExclusive.
*/
FspFsvolDeviceFileRenameAcquireSharedStarveExclusive(FsvolDeviceObject);
/* iterate over notify information and invalidate/notify each file */
for (; (PUINT8)NotifyInfo + sizeof(NotifyInfo->Size) <= NotifyInfoEnd;