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]

Message-ID: <20140831175040.GA17827@core.coreip.homeip.net>
Date:	Sun, 31 Aug 2014 10:50:40 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	gregkh@...uxfoundation.org, falcon@...zu.com, tiwai@...e.de,
	tj@...nel.org, 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 07:44:02AM -0700, Arjan van de Ven wrote:
> On 8/31/2014 2:03 AM, Luis R. Rodriguez wrote:
> >From: "Luis R. Rodriguez" <mcgrof@...e.com>
> >
> >While reviewing Wu Zhangjin's solution to async probe [0] and his
> >ideas on creating async groups I decided to try following the init
> >levels on the kernel to try to help with synchronization at least
> >on some level. This borrows ideas discussed with the kthread_create()
> >solution [1] and also simplifies the idea of how we should be grouping
> >async calls between drivers.
> >
> >A few things worth mentioning. I decided to go down a generic solution as
> >if we ever wanted to bring asynchrnonization behaviour below modules
> >this would allow folks to start testing this without much effort. It
> >allows asynchronous calls to upkeep the order already set in place
> >for built-in code. If one wanted to eventually venture down below
> >that path we'd need to add respective exit calls for each level, as
> >right now we just assume that every level should use module_exit().
> >SmPL grammer could be used to easily tidy this up, for example on
> >the subsys_init():
> 
> before we added the current async approach the approach of async init calls was tried
> At the time, Linus hated it and he was right, it was not the right thing.
> 
> What is different this time to make this the right thing to do ?

Because otherwise drivers still have to do this, but open code it. Let's say I
have a long operations (i.e. for some touchpads it takes about 2 secs to reset
and configure it). I can offload that part into async_schedule() so it does not
stop initialization of the rest of the system (why would I want to delay
initializing of USB or storage system until touchpad is ready?) but if that
initialization fails we end up with partially bound driver and device that is
not really operable. I would very much prefer async and sync cases be the same
- if probe() fails the driver is not bound to the device.

I think it is wrong to make async probing system-wide, but driver opt-in shoudl
be fine and right thing to do.

Thanks.

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