From: Tejun Heo <tj@kernel.org>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: gregkh@linuxfoundation.org, dmitry.torokhov@gmail.com,
tiwai@suse.de, arjan@linux.intel.com, teg@jklm.no,
rmilasan@suse.com, werner@suse.com, oleg@redhat.com,
hare@suse.com, bpoirier@suse.de, santosh@chelsio.com,
pmladek@suse.cz, dbueso@suse.com, mcgrof@suse.com,
linux-kernel@vger.kernel.org,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Joseph Salisbury <joseph.salisbury@canonical.com>,
Kay Sievers <kay@vrfy.org>,
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
Tim Gardner <tim.gardner@canonical.com>,
Pierre Fersing <pierre-fersing@pierref.org>,
Andrew Morton <akpm@linux-foundation.org>,
Nagalakshmi Nandigama <nagalakshmi.nandigama@avagotech.com>,
Praveen Krishnamoorthy <praveen.krishnamoorthy@avagotech.com>,
Sreekanth Reddy <sreekanth.reddy@avagotech.com>,
Abhijit Mahajan <abhijit.mahajan@avagotech.com>,
Casey Leedom <leedom@chelsio.com>,
Hariprasad S <harip
Subject: Re: [PATCH v1 5/5] driver-core: add driver asynchronous probe support
Date: Sun, 28 Sep 2014 11:03:29 -0400 [thread overview]
Message-ID: <20140928150329.GC5023@mtj.dyndns.org> (raw)
In-Reply-To: <1411768637-6809-6-git-send-email-mcgrof@do-not-panic.com>
Hello,
On Fri, Sep 26, 2014 at 02:57:17PM -0700, Luis R. Rodriguez wrote:
...
> Systemd should consider enabling async probe on device drivers
> it loads through systemd-udev but probably does not want to
> enable it for modules loaded through systemd-modules-load
> (modules-load.d). At least on my booting enablign async probe
> for all modules fails to boot as such in order to make this
Did you find out why boot failed with those modules?
> a bit more useful we whitelist a few buses where it should be
> at least in theory safe to try to enable async probe. This
> way even if systemd tried to ask to enable async probe for all
> its device drivers the kernel won't blindly do this. We also
> have the sync_probe flag which device drivers can themselves
> enable *iff* its known the device driver should never async
> probe.
>
> In order to help *test* things folks can use the bus.safe_mod_async_probe=1
> kernel parameter which will work as if userspace would have
> requested all modules to load with async probe. Daring folks can
> also use bus.force_mod_async_probe=1 which will enable asynch probe
> even on buses not tested in any way yet, if you use that though
> you're on your own.
If those two knobs are meant for debugging, let's please make that
fact immediately evident. e.g. Make them ugly boot params like
"__DEVEL__driver_force_mod_async_probe". Devel/debug options ending
up becoming stable interface are really nasty.
> +struct driver_attach_work {
> + struct work_struct work;
> + struct device_driver *driver;
> +};
> +
> struct driver_private {
> struct kobject kobj;
> struct klist klist_devices;
> struct klist_node knode_bus;
> struct module_kobject *mkobj;
> + struct driver_attach_work *attach_work;
> struct device_driver *driver;
> };
How many bytes are we saving by allocating it separately? Can't we
just embed it in driver_private?
> +static void driver_attach_workfn(struct work_struct *work)
> +{
> + int ret;
> + struct driver_attach_work *attach_work =
> + container_of(work, struct driver_attach_work, work);
> + struct device_driver *drv = attach_work->driver;
> + ktime_t calltime, delta, rettime;
> + unsigned long long duration;
This could just be a personal preference but I think it's easier to
read if local vars w/ initializers come before the ones w/o.
> +
> + calltime = ktime_get();
> +
> + ret = driver_attach(drv);
> + if (ret != 0) {
> + remove_driver_private(drv);
> + bus_put(drv->bus);
> + }
> +
> + rettime = ktime_get();
> + delta = ktime_sub(rettime, calltime);
> + duration = (unsigned long long) ktime_to_ns(delta) >> 10;
> +
> + pr_debug("bus: '%s': add driver %s attach completed after %lld usecs\n",
> + drv->bus->name, drv->name, duration);
Why do we have the above printout for async path but not sync path?
It's kinda weird for the code path to diverge like this. Shouldn't
the only difference be the context probes are running from?
...
> +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;
> +
> + if (force_mod_async)
> + return true;
> +
> + mod = drv->owner;
> + if (!safe_mod_async && !mod->async_probe_requested)
> + return false;
> +
> + /* For now lets avoid stupid bug reports */
> + if (!strcmp(bus->name, "pci") ||
> + !strcmp(bus->name, "pci_express") ||
> + !strcmp(bus->name, "hid") ||
> + !strcmp(bus->name, "sdio") ||
> + !strcmp(bus->name, "gameport") ||
> + !strcmp(bus->name, "mmc") ||
> + !strcmp(bus->name, "i2c") ||
> + !strcmp(bus->name, "platform") ||
> + !strcmp(bus->name, "usb"))
> + return true;
Ugh... things like this tend to become permanent. Do we really need
this? And how are we gonna find out what's broken why w/o bug
reports?
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index e4ffbcf..7999aba 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -507,6 +507,13 @@ static void __device_release_driver(struct device *dev)
>
> drv = dev->driver;
> if (drv) {
> + if (drv->owner && !drv->sync_probe) {
> + struct module *mod = drv->owner;
> + struct driver_private *priv = drv->p;
> +
> + if (mod->async_probe_requested)
> + flush_work(&priv->attach_work->work);
This can be unconditional flus_work(&priv->attach_work) if attach_work
isn't separately allocated.
> static int unknown_module_param_cb(char *param, char *val, const char *modname,
> void *arg)
> {
> + int ret;
> + struct module *mod = arg;
Ditto with the order of definitions.
> + if (strcmp(param, "async_probe") == 0) {
> + mod->async_probe_requested = true;
> + return 0;
> + }
Generally looks good to me.
Thanks a lot for doing this! :)
--
tejun
next prev parent reply other threads:[~2014-09-28 15:03 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1411768637-6809-1-git-send-email-mcgrof@do-not-panic.com>
2014-09-26 21:57 ` [PATCH v1 5/5] driver-core: add driver asynchronous probe support Luis R. Rodriguez
2014-09-28 15:03 ` Tejun Heo [this message]
2014-09-29 21:22 ` Luis R. Rodriguez
2014-09-29 21:26 ` Tejun Heo
2014-09-30 7:21 ` Luis R. Rodriguez
2014-10-02 23:29 ` Luis R. Rodriguez
2014-09-29 21:59 ` Greg KH
2014-09-29 22:10 ` Luis R. Rodriguez
2014-09-29 22:24 ` Greg KH
2014-09-28 17:07 ` Tom Gundersen
2014-09-30 2:27 ` Luis R. Rodriguez
2014-09-30 7:47 ` Luis R. Rodriguez
2014-09-30 9:22 ` Tom Gundersen
2014-09-30 15:24 ` Luis R. Rodriguez
2014-10-02 6:12 ` Tom Gundersen
2014-10-02 20:06 ` Luis R. Rodriguez
2014-10-03 8:23 ` Tom Gundersen
2014-10-03 16:54 ` Luis R. Rodriguez
2014-09-28 19:22 ` Dmitry Torokhov
2014-09-30 7:15 ` Luis R. Rodriguez
2014-10-02 23:31 ` Luis R. Rodriguez
2014-10-03 20:11 ` Luis R. Rodriguez
2014-10-03 21:12 ` Luis R. Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140928150329.GC5023@mtj.dyndns.org \
--to=tj@kernel.org \
--cc=abhijit.mahajan@avagotech.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=bpoirier@suse.de \
--cc=dbueso@suse.com \
--cc=dmitry.torokhov@gmail.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=hare@suse.com \
--cc=joseph.salisbury@canonical.com \
--cc=kay@vrfy.org \
--cc=leedom@chelsio.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@do-not-panic.com \
--cc=mcgrof@suse.com \
--cc=nagalakshmi.nandigama@avagotech.com \
--cc=oleg@redhat.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=pierre-fersing@pierref.org \
--cc=pmladek@suse.cz \
--cc=praveen.krishnamoorthy@avagotech.com \
--cc=rmilasan@suse.com \
--cc=santosh@chelsio.com \
--cc=sreekanth.reddy@avagotech.com \
--cc=teg@jklm.no \
--cc=tim.gardner@canonical.com \
--cc=tiwai@suse.de \
--cc=werner@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).