linux-kernel - Re: [RFC v1 0/3] driver-core: add asynch module loading support

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]

Date:	Sun, 31 Aug 2014 15:15:34 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	"Luis R. Rodriguez" <mcgrof@...not-panic.com>, falcon@...zu.com,
	tiwai@...e.de, linux-kernel@...r.kernel.org, oleg@...hat.com,
	akpm@...ux-foundation.org, penguin-kernel@...ove.sakura.ne.jp,
	joseph.salisbury@...onical.com, bpoirier@...e.de,
	"Luis R. Rodriguez" <mcgrof@...e.com>
Subject: Re: [RFC v1 0/3] driver-core: add asynch module loading support

On Sun, Aug 31, 2014 at 05:53:13PM -0400, Tejun Heo wrote:
> Hello, Greg.
> 
> On Sun, Aug 31, 2014 at 01:40:35PM -0700, Greg KH wrote:
> > > Right, all (well almost all) I wanted is for individual drivers to declare
> > > their probe() functions asynchronous and driver core scheduling async attach
> > > and properly handle failures from it.
> > 
> > Yes, that's what I want as well.
> > 
> > Luis, care to redo the patches in this way?  It should be a lot simpler
> > (no messing around with init levels and linker fun...)
> 
> I don't think binding that switch to the driver is gonna work.  This
> is mainly about the behavior expected by the entity which initiated
> module loading not about specific drivers.  I'm fairly certain that
> there are userland scripts which depend on synchronous device probing
> on module loading, especially for storage devices, so we can't simply
> mark, say, libata as needing async probing and do it always
> asynchronously.

For the use cases we have today, it would work.  We have a few drivers
that take a _long_ time in their probe callback, and they need to be
made async for various reasons (modprobe timeout killer, touchscreen
init sequence stalling boot, etc.)

I'm not saying to mark drivers that require synchronous probing with
this flag, that would be broken and wrong.

thanks,

greg k-h
--
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/