linux-kernel - Re: [PATCH] driver core: fix possible missing of device probe

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACVXFVMJaQRj6sUJwiyiMvyAyd2p_8g9cYFqRW2KngQPx62Y5A@mail.gmail.com>
Date:	Fri, 28 Sep 2012 21:53:19 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	anish singh <anish198519851985@...il.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org,
	Russell King <linux@....linux.org.uk>, stable@...r.kernel.org
Subject: Re: [PATCH] driver core: fix possible missing of device probe

On Fri, Sep 28, 2012 at 11:31 AM, anish singh
<anish198519851985@...il.com> wrote:
> Hello Ming,
> Though I am not an expert in this driver core area but
> I have been following this fix.So have some queries below:
>
> On Fri, Sep 28, 2012 at 6:22 AM, Ming Lei <ming.lei@...onical.com> wrote:
>> Inside bus_add_driver(), one device might be added into
> should it not be "driver might be added into"?
>> the bus or probed which is triggered by deferred probe
>> just after completing of driver_attach() and before
>> 'klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers)',
>> so the device won't be probed by this driver.
> So the corresponding device will not be probed.
>>
>> This patch moves the below line
>>
>>         'klist_add_tail(&priv->knode_bus, &bus->p->klist_drivers)'
>>
>> before driver_attach() inside bus_add_driver().
>>
>> So fixes the problem since the below way can guarantee that
>> no probe(dev) may be lost.
>>
> As I understand CPU0 is just calling bus_add_driver and driver_attach
> is called and after that it was pre-empted and cpu1 came into picture.
> Deferred probe started running on cpu1 and it didn't find the driver present
> int the knode_bus and unloaded the driver(why it unloaded is already
> explained by russell in his first post).

If the driver is unloaded, it is not a problem because the device will be
probed after the driver is loaded again, so it is nothing to do with driver
unloading. I don't know it was mentioned before.

The  problem is that the bus_probe_device or device_add context
may not see the driver added in driver_register context, in which
the device is not being seen by driver_attach too. Only when the
device is not probed in both the two contexts, the problem is
triggered.

If the device can be guaranteed to be probed always in one of the
two contexts, the problem will be solved. That is the idea in the patch.

> Hope my understanding is correct.

Hope I clarify the problem.


Thanks,
--
Ming Lei
--
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/