errors during umount make SysRq fail

From: Carl-Daniel Hailfinger
Date: Tue Nov 09 2004 - 12:45:35 EST


having removed an USB disk while umount for it was still running (yes,
that was stupid) I noticed that umount for this device hangs forever in
D state. That would be ok (consequences for user error), however *all*
other umounts I attempt also hang in D state and SysRq-U also hangs,
resulting in a broken system on the next reboot.

I assume the locking against concurrent umount is there to protect
against non-trivial namespace problems and makes sense for normal
umounting, but IIRC SysRq-U is there to ensure consistent filesystems
on the next startup. Would it make sense to allow SysRq-U to break
these locks?

Similar problem exists with SysRq-S. If syncing of one device hangs,
it will never proceed to the next one in the list. I agree that one
is not trivial (stacked devices, loop et al), but can't we make a
best effort to sync at least the physical devices in the machine?
Please don't shoot me for talking about physical devices, I know
there are some really grey areas trying to define that.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at