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: Sun, 28 Sep 2014 12:22:47 -0700 From: Dmitry Torokhov <dmitry.torokhov@...il.com> To: "Luis R. Rodriguez" <mcgrof@...not-panic.com> Cc: gregkh@...uxfoundation.org, tiwai@...e.de, tj@...nel.org, arjan@...ux.intel.com, teg@...m.no, rmilasan@...e.com, werner@...e.com, oleg@...hat.com, hare@...e.com, bpoirier@...e.de, santosh@...lsio.com, pmladek@...e.cz, dbueso@...e.com, mcgrof@...e.com, linux-kernel@...r.kernel.org, Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>, Joseph Salisbury <joseph.salisbury@...onical.com>, Kay Sievers <kay@...y.org>, One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>, Tim Gardner <tim.gardner@...onical.com>, Pierre Fersing <pierre-fersing@...rref.org>, Andrew Morton <akpm@...ux-foundation.org>, Nagalakshmi Nandigama <nagalakshmi.nandigama@...gotech.com>, Praveen Krishnamoorthy <praveen.krishnamoorthy@...gotech.com>, Sreekanth Reddy <sreekanth.reddy@...gotech.com>, Abhijit Mahajan <abhijit.mahajan@...gotech.com>, Casey Leedom <leedom@...lsio.com>, Hariprasad S <hariprasad@...lsio.com>, MPT-FusionLinux.pdl@...gotech.com, linux-scsi@...r.kernel.org, netdev@...r.kernel.org Subject: Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support Hi Luis, On Fri, Sep 26, 2014 at 02:57:17PM -0700, Luis R. Rodriguez wrote: > +static bool drv_enable_async_probe(struct device_driver *drv, > + struct bus_type *bus) > +{ > + struct module *mod; > + > + if (!drv->owner || drv->sync_probe) > + return false; This bit is one of the biggest issues I have with the patch set. Why async probing is limited to modules only? I mentioned several times that we need async probing for built-in drivers and the way you are structuring the flags (async by default for modules, possibly opt-out of async for modules, forcibly sync for built-in) it is hard to extend the infrastructure for built-in case. Also, as far as I can see, you are only considering the case where driver is being bound to already registered devices. If you have a module that creates a device for a driver that is already loaded and takes long time to probe you would still be probing synchronously even if driver/module requested async behavior. So for me it is NAK in the current form. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists