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 12:24:46 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.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

>> 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.
>

I am completely fine if we make basically an async wrapper for
pci_register_driver() and friends.. that would be convenient I suppose.

(but then again, in reality very few drivers take real time to init... most already
do the heavy work in open(). Not all can, sure, but if you look at a bootgraph.pl
graph of a typical boot it's only a few that matter).
And many drivers need to register with a subsystem, and there's some ordering around that,
and that's why we ended up with the async cookie stuff, so that you can do the
heavy work in parallel, but order near the end at registeration-with-the-subsystem time.

But doing this on an initcall level was wrong back then, and I have yet to hear
a reason why it would be right this time.



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