linux-kernel - Re: [PATCH] driver core: add wait event for deferred probe

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:	Thu, 14 Feb 2013 10:04:52 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	anish singh <anish198519851985@...il.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Haojian Zhuang <haojian.zhuang@...aro.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	viro@...iv.linux.org.uk, rusty@...tcorp.com.au,
	hpa@...ux.intel.com, jim.cromie@...il.com,
	linux-kernel@...r.kernel.org,
	Linus Walleij <linus.walleij@...aro.org>,
	broonie@...nsource.wolfsonmicro.com,
	Patch Tracking <patches@...aro.org>
Subject: Re: [PATCH] driver core: add wait event for deferred probe

On Thu, Feb 14, 2013 at 09:56:36AM +0000, Arnd Bergmann wrote:
> I would put it this way: With the introduction of deferred probing, the
> rules for the use of __init sections have changed slightly for some
> corner cases. While normal device drivers can, as before, not call
> __init functions from their .probe() callbacks, we could do that in
> drivers as long as they were built-in and did not support hotplug,
> and that exception was used in console drivers. This exception has
> now become more specific, and those drivers also must not use
> deferred probing that depends on other loadable modules or hotpluggable
> devices.

In the general case, that remains true, but it's still _not_ true for
console drivers.

The console _should_ be initialised before it is attempted to be opened
before passing control to userspace, which happens before the .init
section is freed.

If the console is deferred past that point, then userspace has no console.
The behaviour of userspace in that situation can be very interesting, and
I'd suggest that such is not well tested; consider the effect of not
having fd 0,1,2 connected to something like a console but your filesystem
and something doing a printf().  You can hope that userspace will take
care of that condition, but I personally would not put much faith in it.

With the plethora of 'init' daemon solutions we now have, I have less
faith than I used to that such a condition would be correctly handled
by all of them.
--
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/