linux-kernel - Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism

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, 14 Oct 2011 13:07:21 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Ming Lei <tom.leiming@...il.com>,
	Andrei Warkentin <awarkentin@...are.com>,
	Greg KH <greg@...ah.com>, Dilan Lee <dilee@...dia.com>,
	"G, Manjunath Kondaiah" <manjugk@...com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
	Josh Triplett <josh@...htriplett.org>, Manjunath@...per.es,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Linux PM List <linux-pm@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism

On Fri, Oct 14, 2011 at 12:39 PM, Alan Stern <stern@...land.harvard.edu> wrote:
> On Fri, 14 Oct 2011, Grant Likely wrote:
>> I'd be much happier to find a way to do this in core code though.  And
>> there is still a potential race condition here.  For example, if G is
>> in the middle of it's probe routine, and D gets probed between G
>> registering GPIOs and calling dpm_move_last(), then we're in the same
>> boat again.
>
> Of course, this means that G must call dpm_move_last() _before_
> registering its GPIOs.  So the overall flow of a probe routine is
> simple enough:
>
>        1. Check that all the resources you need are available.
>
>        2. If not, defer your probe.  If yes, call dpm_move_last().
>
>        3. Finish the probe, including registration of resources
>           that will be available to other drivers (such as child
>           devices).

Alright, let's start with this.  That also means that the current
probe deferral patch doesn't need to have any knowledge of dpm_list
added to it.  It will be required only of the users.

I'd still like to look closely at the ordering of dpm_list for the
non-deferred use case, but that can be an entirely separate patch set.
 It doesn't need to block the probe deferral work.

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