[lkml]   [2002]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Driverfs updates
On Tue, 9 Jul 2002 09:56:55 -0700 (PDT), Patrick Mochel
<> wrote:

>On Tue, 9 Jul 2002, Keith Owens wrote:
>> On Mon, 8 Jul 2002 11:41:52 -0700 (PDT),
>> Patrick Mochel <> 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

john alvord
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:27    [W:0.128 / U:1.240 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site