Stephen Cameron wrote: > stefanr@xxxxxxxxxxxxxxxxx wrote: >> The sg driver's open method takes a reference to the underlying SCSI >> device representation of the mid layer. Among else, this step increases >> the module use count of the respective low-level driver (transport layer >> driver) so that the SCSI mid layer can be sure that function pointers to >> driver methods stay valid during the lifetime of the SCSI device >> representation. >> >> This reference taking is of course being reversed when the sg driver >> finishes its last uses of the underlying SCSI device. This may be at >> the respective close() or even later. >> >> In short, it is normal, expected, and necessary what you are seeing. >> -- >> Stefan Richter >> > > I don't think you are correct. Look more closely at my test cases. > > When I attempt the rmmod, *nothing* has the device open. The last > close has already occurred -- albeit *after* the device was > removed. Yep, sorry, I didn't read your report as carefully as necessary. > In my test, the module *never* becomes rmmod-able. Doesn't matter > how long you wait, and nothing will ever decrement the reference > count. Did you check that also after, say, several minutes? I suppose you already looked at the kernel log for possibly related messages and would have reported them as well... Nevertheless, I have seen some cases of device removal or driver removal where the SCSI layer spent many minutes (5? 15? I'm not sure anymore) in error handling although the lower layer had done its best (best but perhaps not well) to report the device as physically gone. Did you already test really long after device removal and last close, along the lines of this? # while ((i++ < 20)); do rmmod $driver && break; sleep 60; done -- Stefan Richter -=====-==-=- ---= -==== http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
