lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 31 Oct 2012 17:55:29 -0700
From:	Russ Dill <Russ.Dill@...com>
To:	Pantelis Antoniou <panto@...oniou-consulting.com>
Cc:	Tony Lindgren <tony@...mide.com>,
	linux-arm-kernel@...ts.infradead.org,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	Koen Kooi <koen@...inion.thruhere.net>,
	Matt Porter <mporter@...com>, linux-omap@...r.kernel.org
Subject: Re: [RFC 1/7] capebus: Core capebus support

On Wed, Oct 31, 2012 at 3:07 PM, Pantelis Antoniou
<panto@...oniou-consulting.com> wrote:
>
> On Oct 31, 2012, at 11:55 PM, Russ Dill wrote:
>
>> On Wed, Oct 31, 2012 at 9:52 AM, Pantelis Antoniou
>> <panto@...oniou-consulting.com> wrote:
>>> Introducing capebus; a bus that allows small boards (capes) to connect
>>> to a complex SoC using simple expansion connectors.
>>>
>
> [snip]
>>> +       if (drv) {
>>> +               /* call the removed bus method (if added prev.) */
>>> +               if (cape_dev->added) {
>>> +                       BUG_ON(cape_dev->bus == NULL);
>>> +                       BUG_ON(cape_dev->bus->ops == NULL);
>>> +                       if (cape_dev->bus->ops->dev_removed)
>>> +                               cape_dev->bus->ops->dev_removed(cape_dev);
>>> +                       cape_dev->added = 0;
>>> +               }
>>
>> Is there any case where added will not track drv?
>
>
> Yes, there is a corner case here.
>
> There is the case where while the device is created there is no matching
> driver yet. Either that's the case of a not supported cape, or the
> cape driver hasn't been loaded yet.
>
> We do need the device to be created, so that the user can browse in the
> sysfs it's eeprom attributes.
>
> There's some further complications with runtime cape overrides, but
> that's the gist of it.

I'm trying to figure out how that would come about, here is where
added is set to 1:

+       /* all is fine... */
+       cape_dev->driver = drv;
+       cape_dev->added = 1;

This is after calling drv->probe, so drv is not null.

There is a brief time here where added is 0, but driver is not.

+       if (drv) {
+               /* call the removed bus method (if added prev.) */
+               if (cape_dev->added) {
+                       BUG_ON(cape_dev->bus == NULL);
+                       BUG_ON(cape_dev->bus->ops == NULL);
+                       if (cape_dev->bus->ops->dev_removed)
+                               cape_dev->bus->ops->dev_removed(cape_dev);
+                       cape_dev->added = 0;
+               }
+               if (drv->remove) {
+                       pm_runtime_get_sync(dev);
+                       drv->remove(cape_dev);
+                       pm_runtime_put_noidle(dev);
+               }
+               cape_dev->driver = NULL;

Is one of the remove or resume functions check added in this case?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ