Messages in this thread | | | From | John Alvord <> | Subject | Re: Driverfs updates | Date | Wed, 10 Jul 2002 17:40:22 -0700 |
| |
On Tue, 9 Jul 2002 09:56:55 -0700 (PDT), Patrick Mochel <mochel@osdl.org> wrote:
> >On Tue, 9 Jul 2002, Keith Owens wrote: > >> On Mon, 8 Jul 2002 11:41:52 -0700 (PDT), >> Patrick Mochel <mochel@osdl.org> wrote: >> >- Add struct module * owner field to struct device_driver >> >- Change {get,put}_driver to use it >> >> struct device_driver * get_driver(struct device_driver * drv) >> { >> if (drv && drv->owner) >> if (!try_inc_mod_count(drv->owner)) >> return NULL; >> return drv; >> } >> >> is racy. The module can be unloaded after if (drv->owner) and before >> try_inc_mod_count. To prevent that race, drv itself must be locked >> around calls to get_driver(). >> >> The "normal" method is to have a high level lock that controls the drv >> list and to take that lock in the register and unregister routines and >> around the call to try_inc_mod_count. drv->bus->lock is no good, >> anything that relies on reading drv without a lock or module reference >> count is racy. I suggest you add a global driverfs_lock. > >This race really sucks. > >Adding a high level lock is no big deal, but I don't think it will solve >the problem. Hopefully you can educate me a bit more. > >If you add a driver_lock, you might have something like: > > struct device_driver * d = NULL; > > spin_lock(&driver_lock); > if (drv && drv->owner) > if (try_inc_mod_count(drv->owner)) > d = drv; > > spin_unlock(&driver_lock): > return d; > >...but, what if someone has unloaded the module before you get to the if >statement? The memory for the module has been freed, including drv itself. > >How do you protect against that? The simplest solutions, given the current >infrastructure, are: > >- The BKL >- Not allowing module unload >- Ignoring it, and hoping it goes away > >None of those solutions are ideal, though I don't have any bright ideas >off the top of my head.
The only idea I can see is to have a single kernel-thread process which would do each load/unload request serially on a single processor.
john alvord - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |