On Sat, 18 Sep 2004, Nix N. Nix wrote: > Rather, when I mount a partition, it should become impossible > to rmmod ehci_hcd (or uhci_hcd, or whichever host controller the drive > happens to be going through at the time) and all other modules involved > in the access to the file system (such as sd_mod), because they are now > part of the pipeline towards the drive. Is this the "known bug" ?
Not really, although it is related. Doing what you say would be difficult, because the knowledge that the device file is open (if the drive is mounted, for instance) is confined to the SCSI layer and below, whereas the modules needing to be pinned are usb-storage and above. However, another approach that would work equally well would be to increase the reference count of an HC driver for each USB device attached to it. The "known bug" is that when an HCD module is rmmod'ed it doesn't wait for all the USB device refcounts to go to 0 -- but when they do a routine in the HCD is called to release some memory. Of course, if the HCD code has already been unloaded from the system this causes an oops, as you found out. There are other ways to delay USB device refcounts besides usb-storage; it's possible to trigger the same bug using usbfs for example. > I don't know the ramifications of incrementing the reference count on > the appropriate modules when mounting a partition from its controlled > USB drive, which is why I also submitted a bug report with the > distribution I'm using (http://bugs.gentoo.org/show_bug.cgi?id=64562), > pointing to the fact that their "hotplug" rc service causes ehci_hcd > (and pretty much all USB-related stuff) to be rmmod-ed upon shutdown, > regardless of whether they are still in use or not. That's a good thing to report. In fact, I don't know of any reason to rmmod any drivers upon shutdown. On Sat, 18 Sep 2004, Pete Zaitcev wrote: > > Correct me if I'm wrong: If one of the controlled devices is still open, > > shouldn't the reference count on the modules involved (including the > > appropriate hcd) be incremented to prevent rmmod ? I don't mean to say > > that as soon as I connect the drive it should be impossible to rmmod > > ehci_hcd. [] > > Such a case can be made, but this is not how Linux USB stack is designed. > Its HC drivers are removable regardless of its users. The USB core is > supposed to isolate users. An exception is when an URB is in transit, > in which case the HC driver cannot be removed. Pete is right. The USB stack has always worked like this. I don't know why the decision was made this way, but it sort of makes sense. After all, what point is there in trying to prevent the user from unloading the HC driver when he can simply unplug the USB cable? > However, if rmmod for an HCD causes oopses, it's a bug. What Alan described > is such bug. It is not supposed to happen despite HCDs being unloadable. > > In 2.4 at least, there is a long standing bug in usb-storage where unloading > it (not an HCD) causes an oops if a CBI transport device was connected. > The usb-storage forgets to unlink the interrupt URB and when a callback > occurs, the system oopses in an interrupt. It's an example of a similar bug, > which everyone knows and nobody has fixed so far. There's not much interest > in helping people unloading modules, if they cannot help themselves. > I'm very open for patches in this area, but I'm not going to go in and > fix this. Your case might be similar. > > This is only my personal view though. It may be erroneous. This very issue was discussed on LKML early in the year, and Linus himself said that he didn't much care about providing support for unloading modules -- as far as he was concerned the ability to unload a module was only a convenience for developers, and ordinary users should be able run okay without ever unloading any drivers. This particular bug is just one example of a whole family, all involving unloading modules while parts of them are still in use. They are all preventable in theory, but to do so would require changing the way loadable modules are implemented internally. It could be done, and people have been thinking about it, but I don't know whether anything will happen in the near future. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
