> On Tue Jun 04 2002 - 11:25:19 EST,
> Patrick Mochel <firstname.lastname@example.org> wrote:
> > When a driver is removed, the list of devices that it supports is
> > iterated over, and the driver's remove callback is called for each
> > one. The device is removed from that list and the symlinks removed.
> Maybe I'm blind, but I can't see how this works without races for
> bridge device drivers. Imagine for example what happens when I rmmod
> a usb hcd driver. Its module use count should be zero as long as the
> devices attached to it are not in use, right?
> When I e.g. open a file in directory of a device behind my hcd, the
> devices use count is incremented but can still remove the driver.
> Reading the file after module unload then can do bad things if the
> show() callback was inside the hcd driver.
> Did I miss the obvious anywhere?
No, that's a race that would affect all modular drivers. Ideally, we would
want to pin the module in memory on file open, then decrement the usage
count on close. We could do this by adding a struct module field to struct
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/