From: gregkh@linuxfoundation.org (Greg Kroah-Hartman)
To: linux-arm-kernel@lists.infradead.org
Subject: [BUG] Deferred probing in driver model is racy, resulting in lost probes
Date: Wed, 26 Sep 2012 13:08:33 -0700 [thread overview]
Message-ID: <20120926200833.GA14340@kroah.com> (raw)
In-Reply-To: <CACVXFVOZ=4HFAy38q_8ZUjOPffcv_mMTi7KCdh3HcX=MCLw5SQ@mail.gmail.com>
On Sun, Sep 16, 2012 at 09:24:43PM +0800, Ming Lei wrote:
> On Sun, Sep 16, 2012 at 4:25 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >
> > It isn't. As I said, it's a race condition due to lack of locking - the
> > driver hasn't been added to the list of drivers at this point:
> >
> > int bus_add_driver(struct device_driver *drv)
> > {
> > ...
> > if (drv->bus->p->drivers_autoprobe) {
> > error = driver_attach(drv);
> > if (error)
> > goto out_unregister;
> > }
> > klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers);
> > ...
> > }
> >
> > Notice that the attaching is done _before_ the driver is added to the
> > bus driver list.
>
> Yes, it is a problem since a new device may be added to bus
> and bus_probe_device() may not see the new added driver.
>
> So looks klist_add_tail() should complete before driver_attach()
> inside bus_add_driver().
>
> The attached one line change should fix the problem because the
> below way can guarantee that no probe(dev) may be lost.
>
>
> CPU0 CPU1
> driver_register
> ...
> write(bus->driver_list)
> smp_mb()
> read(bus->device_list)
> ...
> device_add
> /* bus_add_device */
> write(bus->device_list)
> smp_mb()
> /* bus_probe_device*/
> read(bus->driver_list)
>
> And the smp_mb() has been implicit by UNLOCK+LOCK
> of 'klist' according to 'VARIETIES OF MEMORY BARRIER' part
> of Documentation/memory-barriers.txt.
>
> Could you test the below patch to see if it can fix your problem?
>
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index 181ed26..17d7437 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
> @@ -714,12 +714,12 @@ int bus_add_driver(struct device_driver *drv)
> if (error)
> goto out_unregister;
>
> + klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers);
> if (drv->bus->p->drivers_autoprobe) {
> error = driver_attach(drv);
> if (error)
> goto out_unregister;
> }
> - klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers);
> module_add_driver(drv->owner, drv);
>
> error = driver_create_file(drv, &driver_attr_uevent);
>
>
>
Did the above patch ever prove to solve the issue or not?
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Ming Lei <tom.leiming@gmail.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Grant Likely <grant.likely@secretlab.ca>,
Arnd Bergmann <arnd@arndb.de>,
Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: [BUG] Deferred probing in driver model is racy, resulting in lost probes
Date: Wed, 26 Sep 2012 13:08:33 -0700 [thread overview]
Message-ID: <20120926200833.GA14340@kroah.com> (raw)
In-Reply-To: <CACVXFVOZ=4HFAy38q_8ZUjOPffcv_mMTi7KCdh3HcX=MCLw5SQ@mail.gmail.com>
On Sun, Sep 16, 2012 at 09:24:43PM +0800, Ming Lei wrote:
> On Sun, Sep 16, 2012 at 4:25 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> >
> > It isn't. As I said, it's a race condition due to lack of locking - the
> > driver hasn't been added to the list of drivers at this point:
> >
> > int bus_add_driver(struct device_driver *drv)
> > {
> > ...
> > if (drv->bus->p->drivers_autoprobe) {
> > error = driver_attach(drv);
> > if (error)
> > goto out_unregister;
> > }
> > klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers);
> > ...
> > }
> >
> > Notice that the attaching is done _before_ the driver is added to the
> > bus driver list.
>
> Yes, it is a problem since a new device may be added to bus
> and bus_probe_device() may not see the new added driver.
>
> So looks klist_add_tail() should complete before driver_attach()
> inside bus_add_driver().
>
> The attached one line change should fix the problem because the
> below way can guarantee that no probe(dev) may be lost.
>
>
> CPU0 CPU1
> driver_register
> ...
> write(bus->driver_list)
> smp_mb()
> read(bus->device_list)
> ...
> device_add
> /* bus_add_device */
> write(bus->device_list)
> smp_mb()
> /* bus_probe_device*/
> read(bus->driver_list)
>
> And the smp_mb() has been implicit by UNLOCK+LOCK
> of 'klist' according to 'VARIETIES OF MEMORY BARRIER' part
> of Documentation/memory-barriers.txt.
>
> Could you test the below patch to see if it can fix your problem?
>
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index 181ed26..17d7437 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
> @@ -714,12 +714,12 @@ int bus_add_driver(struct device_driver *drv)
> if (error)
> goto out_unregister;
>
> + klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers);
> if (drv->bus->p->drivers_autoprobe) {
> error = driver_attach(drv);
> if (error)
> goto out_unregister;
> }
> - klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers);
> module_add_driver(drv->owner, drv);
>
> error = driver_create_file(drv, &driver_attr_uevent);
>
>
>
Did the above patch ever prove to solve the issue or not?
thanks,
greg k-h
next prev parent reply other threads:[~2012-09-26 20:08 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-18 14:58 [BUG] Deferred probing in driver model is racy, resulting in lost probes Russell King - ARM Linux
2012-08-18 14:58 ` Russell King - ARM Linux
2012-09-15 16:03 ` Greg Kroah-Hartman
2012-09-15 16:03 ` Greg Kroah-Hartman
2012-09-15 18:32 ` Russell King - ARM Linux
2012-09-15 18:32 ` Russell King - ARM Linux
2012-09-16 6:41 ` Ming Lei
2012-09-16 6:41 ` Ming Lei
2012-09-16 8:25 ` Russell King - ARM Linux
2012-09-16 8:25 ` Russell King - ARM Linux
2012-09-16 13:24 ` Ming Lei
2012-09-16 13:24 ` Ming Lei
2012-09-26 20:08 ` Greg Kroah-Hartman [this message]
2012-09-26 20:08 ` Greg Kroah-Hartman
2012-09-26 20:23 ` Russell King - ARM Linux
2012-09-26 20:23 ` Russell King - ARM Linux
2012-09-26 20:36 ` Greg Kroah-Hartman
2012-09-26 20:36 ` Greg Kroah-Hartman
2012-09-26 23:47 ` Ming Lei
2012-09-26 23:47 ` Ming Lei
2012-09-27 13:58 ` Russell King - ARM Linux
2012-09-27 13:58 ` Russell King - ARM Linux
2012-09-27 14:03 ` Russell King - ARM Linux
2012-09-27 14:03 ` Russell King - ARM Linux
2012-09-27 14:15 ` Ming Lei
2012-09-27 14:15 ` Ming Lei
2012-09-27 17:22 ` Joachim Eastwood
2012-09-27 17:22 ` Joachim Eastwood
2012-09-27 17:26 ` Mark Brown
2012-09-27 17:26 ` Mark Brown
2012-09-28 0:30 ` Ming Lei
2012-09-28 0:30 ` Ming Lei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120926200833.GA14340@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.