The problem is that if something ends up holding the mount open, then
ide_unregister fails, and since it returns void, the failure goes unreported
and the kernel ends up stuck in a bad state.
The lack of umount -f is certainly a problem, but I'd also like unregister_ide
to *do* something sensible if the device is busy.
IT seems that there are three things that can keep a device registered:
- the drive->busy flag (used for occasional whole-drive operations; while
it's set, operations wait on the drive->wqueue)
- drive->usage non-zero, which is an open count. (note that this can only
count up to 255 - is there a bug if someone opens the device too many
times?)
- DRIVER(drive)->cleanup returning non-zero. This is driver-specific
and will presumably not block unregistration unreasonably.
I'd like to have ide_unregister set a "zombie" flag in all the affected
devices if they can't be immediately unregistered. This flag wound
make accesses fail fast (rather than spending 10 seconds retrying
during which the machine is effectively locked up), and when the usage
and busy flags are cleared, it would force a re-execution of
ide_unregister. The number of places that these flags are decreased or
cleared appears to be fairly small, so the overhead should not be
severe.
Achieving the "fail fast" through testing the flag before trying I/O
seems potentially troublesome, however. Can anyone think of a clean way to
do that? Set the busy flag and put the zombie test in the execptional
branch?
Are there serious problems with this technique? Does it seem unbearably
ugly?
One question: in the ide_drive_t structure, there are already 16 bits
allocated in the bit-field range. (If FAKE_FDISK_FOR_EZDRIVE is
set.) Should I just add another flag there? Is there a reason why
the booleans before that are bytes and not bits?
Does anyone understand why, in ide_open, the system has to increment
drive_>usage *before* verifying that everything is okay? Could another
close sneak in, or is it safe to assume that the final drive->usage
does not have to be checked to see if it's the final decrement
(assuming it was not zero to start with)? And is it a bug that
drive->usae is left incremented even if driver->open fails and
MOD_DEC_USE_COUNT is called?
I'm just trying to understand this thoroughly...
-- -Colin- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/