linux-kernel - Re: [PATCH v4 21/22] driver core: Start processing deferred probes earlier

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:	Fri, 11 Sep 2015 13:24:23 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Tomeu Vizoso <tomeu.vizoso@...labora.com>
Cc:	linux-kernel@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Javier Martinez Canillas <javier@....samsung.com>,
	Thierry Reding <thierry.reding@...il.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	linux-arm-kernel@...ts.infradead.org,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	devicetree@...r.kernel.org,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-acpi@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v4 21/22] driver core: Start processing deferred probes
 earlier

On Mon, Sep 07, 2015 at 02:23:46PM +0200, Tomeu Vizoso wrote:
> Some initcalls in the late level assume that some devices will have
> already probed without explicitly checking for that.
> 
> After the recent move to defer most device probes when they are
> registered, pressure increased in the late initcall level.
> 
> By starting the processing of the deferred queue in device_initcall_sync
> we increase the chances that the initcalls mentioned before will find
> the devices they depend on to have already probed.

Which cases do we have that are outside the driver model and thus
affected by this?  USB gadgets are one case I'm aware of, and cpufreq is
still problematic.  I'm wondering if it might be tractable to address
the actual problems with the remaining reliance on init ordering here.

I'm also wondering if we might end up running into situations where this
makes the problem with havinng to defer probes more of an issue on some
systems - since we start trying earlier while we are still doing our
first pass initialisation we could end up deferring some device then
retrying it a bunch of times while going through the earlier phases of
init as we continue to register more devices.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)