linux-kernel - Re: [PATCH 1/3] driver core: Add API to wait for deferred probe to complete during init

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, 9 May 2013 15:37:02 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	Mike Turquette <mturquette@...aro.org>,
	Ming Lei <tom.leiming@...il.com>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Saravana Kannan <skannan@...eaurora.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Liam Girdwood <lrg@...com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/3] driver core: Add API to wait for deferred probe to
 complete during init

On Thu, May 09, 2013 at 03:14:45PM +0100, Russell King - ARM Linux wrote:
> On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote:

> > Even if the driver copes fine it can still be desirable to avoid the
> > power down/up cycle if it involves some user visible effect - things
> > like blinking the display off then on for example.  That said I am a
> > little suspicious about this approach, it doesn't feel as robust as it
> > should to go round individual callers.

> What if the driver for something like your display is a module which
> needs to be loaded from userland?

That's clearly a "don't do that then" sort of thing; while we don't want
to be unhelpful there's no guarantees with this approach.

> Where the design bug lies is in the "lets probe all the drivers and then
> shut down resources which drivers haven't claimed".  That contains an
> implied assumption: that all drivers have been loaded and probed at the
> point where you shut down those resources.

Well, that's not really the intention - it's not a strong guarantee,
it never has been given things like the module case you mention.

> So, trying to solve the problem may be totally fruitless because you
> can't actually solve it - you can only put a sticky plaster over it and
> hope that it catches most of the problem.  But reality is that you can't
> have both a shutdown of unused resources _and_ avoid the down/up cycle.

Yes, exactly - all we're trying to do here is cover the 90% case, not
solve all the possible problems since as you say that's not achievable.  
There's a clear and reasonable desire to turn off resources we know
aren't in use at the current time, but equally well doing so as soon as
we start controlling the resources is pretty much guranteed to introduce
user visible issues on some systems so it's a question of picking some
reasonable point after that.

Another option here which is more in tune with deferred probing and
hotplugging would be to switch the delay over to be time based rather
than initcall based; do the shutdown at some point based on the time the
last resource was registered.  That still won't cover everything
though we could make the delay tunable.

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