linux-kernel - Re: [PATCH 2/8] driver-core: add asynchronous probing support for drivers

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: <20150703183002.GE7021@wotan.suse.de>
Date:	Fri, 3 Jul 2015 20:30:02 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Dan Williams <dan.j.williams@...il.com>,
	Tom Gundersen <teg@...m.no>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Tejun Heo <tj@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Olof Johansson <olof@...om.net>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Subject: Re: [PATCH 2/8] driver-core: add asynchronous probing support for
 drivers

On Sat, Jun 27, 2015 at 04:45:25PM -0700, Dan Williams wrote:
> On Mon, Mar 30, 2015 at 4:20 PM, Dmitry Torokhov
> <dmitry.torokhov@...il.com> wrote:
> > Some devices take a long time when initializing, and not all drivers are
> > suited to initialize their devices when they are open. For example,
> > input drivers need to interrogate their devices in order to publish
> > device's capabilities before userspace will open them. When such drivers
> > are compiled into kernel they may stall entire kernel initialization.
> >
> > This change allows drivers request for their probe functions to be
> > called asynchronously during driver and device registration (manual
> > binding is still synchronous). Because async_schedule is used to perform
> > asynchronous calls module loading will still wait for the probing to
> > complete.
> >
> > Note that the end goal is to make the probing asynchronous by default,
> > so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a temporary
> > measure that allows us to speed up boot process while we validating and
> > fixing the rest of the drivers and preparing userspace.
> >
> > This change is based on earlier patch by "Luis R. Rodriguez"
> > <mcgrof@...e.com>
> >
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...il.com>
> > ---
> >  drivers/base/base.h    |   1 +
> >  drivers/base/bus.c     |  31 +++++++---
> >  drivers/base/dd.c      | 149 ++++++++++++++++++++++++++++++++++++++++++-------
> >  include/linux/device.h |  28 ++++++++++
> >  4 files changed, 182 insertions(+), 27 deletions(-)
> 
> Just noticed this patch.  It caught my eye because I had a hard time
> getting an open coded implementation of asynchronous probing to work
> in the new libnvdimm subsystem.  Especially the messy races of tearing
> things down while probing is still in flight.  I ended up implementing
> asynchronous device registration which eliminated a lot of complexity
> and of course the bugs.  In general I tend to think that async
> registration is less risky than async probe since it keeps wider
> portions of the traditional device model synchronous 

but its not see -DEFER_PROBE even before async probe.

> and leverages the
> fact that the device model is already well prepared for asynchronous
> arrival of devices due to hotplug.

I think this sounds reasonable, do you have your code upstream or posted?
If not will you be at Plumbers? Maybe we shoudl talk about this as although
ChromeOS already likely already jumped on async probe we should address a
way forward and path forward for other distributions and I don't think anyone
is looking too much into it. async probe came to Linux for two reasons:

 * chromeos wanting it
 * an incorrect systemd assumption on how the driver core works

So long term we still need to address the systemd approach, are they going
to be defaulting now to async probe for all modules? How about for built-ins?

We should talk about this and maybe at plumbers.

> Splitting the "initial probe" from
> the "manual probe" case seems like a recipe for confusion.

If you can come up with pros / cons on both strategies it'd be
valuable.

  Luis
--
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/