Messages in this thread | | | Date | Sat, 14 Nov 1998 03:43:38 -0700 (MST) | From | Colin Plumb <> | Subject | Hacking ide.c for better pcmcia support... |
| |
I've been looking over ide_unregister and contemplating its failings when someone ejects a PCMCIA IDE card. (In my case, it's a flash ROM card.)
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/
| |