lkml.org 
[lkml]   [2002]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Driverfs updates
    Date
    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/

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