Fix system hang on USB/removable device removal - #93
Merged
bobranten merged 2 commits intoMar 5, 2026
Conversation
When a USB drive with an ext4 filesystem is removed while the driver has outstanding I/O, the system hangs indefinitely because KeWaitForSingleObject calls block forever waiting for completions that will never arrive from the removed device. This commit fixes the issue with three changes: - block.c: add 30-second timeouts to all KeWaitForSingleObject calls and cancel pending IRPs on timeout instead of waiting forever - pnp.c: set VCB_DEVICE_REMOVED flag early in both PnpRemove and PnpSurpriseRemove so concurrent I/O threads can fail fast - read.c, write.c: check VCB_DEVICE_REMOVED flag before issuing new I/O and return STATUS_NO_SUCH_DEVICE immediately
HorusGod007
force-pushed
the
fix/prevent-hang-on-device-removal
branch
from
March 4, 2026 13:26
5f1270b to
d0f12d7
Compare
Owner
|
This looks like a reasonable change, are you finished so I should aply it?
|
The previous commit missed three infinite KeWaitForSingleObject calls: - pnp.c: Ext2PnpRemove and Ext2PnpSurpriseRemove wait forever for the lower driver to complete the PnP IRP after device removal - fsctl.c: Ext2IsMediaWriteProtected waits forever for the write-protect check IRP to complete All three now use 30-second timeouts with IRP cancellation on timeout, matching the pattern used in block.c.
Author
yes just finished and tested in test mode. all good now. |
|
Excuse me, my system is having this issue. Do you plan on releasing an update to Ext4Fsd sometime in the near future? I would really like to take advantage of this fix. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
KeWaitForSingleObjectcalls that wait for I/O completion. On timeout, cancel pending IRPs viaIoCancelIrpand returnSTATUS_IO_TIMEOUTinstead of hanging forever.SetLongFlag(Vcb->Flags, VCB_DEVICE_REMOVED)earlier in bothExt2PnpRemoveandExt2PnpSurpriseRemove, before sending the IRP down and dismounting. Add 30-second timeouts to the PnP IRP waits in Remove, SurpriseRemove, and QueryRemove paths.Ext2IsMediaWriteProtectedwhich also waited indefinitely for the lower driver.VCB_DEVICE_REMOVEDflag checks early inExt2ReadandExt2Write, returningSTATUS_NO_SUCH_DEVICEimmediately to prevent new I/O from being issued to a removed device.Problem
When a USB drive formatted with ext2/ext3/ext4 is physically removed while the Ext4Fsd driver has outstanding I/O, the system hangs indefinitely. This happens because
KeWaitForSingleObjectcalls across multiple code paths wait withNULLtimeout (infinite) for I/O completions that will never arrive from the now-removed device. Additionally, theVCB_DEVICE_REMOVEDflag was set too late in the PnP removal path, after dismount, so concurrent threads had no way to detect the removal early.