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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 28 Sep 2012 15:13:38 +0100 From: Russell King - ARM Linux <linux@....linux.org.uk> To: Ming Lei <ming.lei@...onical.com> Cc: anish singh <anish198519851985@...il.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org, stable@...r.kernel.org Subject: Re: [PATCH] driver core: fix possible missing of device probe On Fri, Sep 28, 2012 at 10:07:22PM +0800, Ming Lei wrote: > On Fri, Sep 28, 2012 at 9:55 PM, Russell King - ARM Linux > <linux@....linux.org.uk> wrote: > >> I do not mention threads case in one CPU because the context in > >> which device_add runs will always see the driver added into > > > > There you go again. Look at my _much_ better description of the problem > > and you'll notice that device_add has nothing to do with this. > > OK, I explain it again: > > CPU0 CPU1 > > driver_register > ... > bus_add_driver > driver_attach > device_add(devb) > > klist_add_tail(klist_drivers) > > When device_add(devb) is run just after completion of driver_attach > and before klist_add_tail(klist_drivers), the 'devb' can't be probed > in device_add because the driver hasn't been added into bus, > and it wasn't be probed in driver_attach because driver_attach didn't > see the device in the bus. > > So the 'devb' will be missed to be probed in the bus, won't it? Wait a moment. You're describing a *totally* *different* problem to the problem I reported. I say - for the third time - that in the problem I reported, device_add() has NOTHING TO DO WITH IT. In your previous mail, you complained that my description did not cover another case. I throw that back at you and say to you that _your_ description does _not_ cover my case, but refers to a _different_ problem which happens to be fixed by the _same_ fix. To attach my "reported-by" to a problem description which is not the problem that I reported is bad practice, and actually creates a lie. If you wish to keep your problem description, then you must remove my Reported-by, because the problem you refer to in your description is not _my_ problem. -- 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