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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 28 Sep 2012 20:01:07 +0530
From:	anish kumar <anish198519851985@...il.com>
To:	Ming Lei <ming.lei@...onical.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, 2012-09-28 at 21:53 +0800, Ming Lei wrote:
> 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.
Ming,
Somehow I feel here that the problem reported by Russell is totally
different from your understanding of problem.I humbly urge you to have
a look at Russell's nice explanation.
I was easily able to understand the problem faced by him and the
reasoning put forward by him and moreover if the issue had been related
to SMP russell would have definitely mentioned it given his knowledge of
the same.
Thanks for your time.
> 
> 
> 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/