[lkml]   [2002]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Driverfs updates

    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;

    if (drv && drv->owner)
    if (try_inc_mod_count(drv->owner))
    d = drv;

    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.


    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.027 / U:11.308 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site