linux-kernel - Re: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)

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]

Message-ID: <Pine.LNX.4.44L0.0912090959230.4120-100000@iolanthe.rowland.org>
Date:	Wed, 9 Dec 2009 10:24:04 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Zhang Rui <rui.zhang@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	pm list <linux-pm@...ts.linux-foundation.org>
Subject: Re: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)

On Tue, 8 Dec 2009, Linus Torvalds wrote:

> On Tue, 8 Dec 2009, Alan Stern wrote:
> > 
> > You mean, if A comes before B in the list and A must suspend after B?  
> 
> But if they are not topologically ordered, then A wouldn't necessarily be 
> before B on the list in the first place.

Okay, I see what you're getting at.  Yes, this is quite true -- if A
doesn't precede B in dpm_list then A can't safely wait for B to
suspend.  To put it another way, only list-compatible constraints are
feasible.

This shouldn't be a problem.  If it were we'd be seeing it right now, 
because A would _always_ suspend before B.

> Of course, if we've mucked with the list by hand and made sure the 
> ordering is ok, then that's a different issue. But your whole point seemed 
> to be that the device could impose its own ordering in its suspend 
> callback, which is not true on its own without external ordering.

No, sorry for not making it clearer.  I was assuming all long that the 
non-tree constraints were compatible with the list ordering.

In fact these considerations already affect the USB resume operations, 
even without asynchronous resume.  The code relies on the fact that the 
PCI layer registers sibling devices on a slot in order of increasing 
function number.  There's no guarantee this will remain true in the 
future (it may already be wrong AFAIK), so putting in some explicit 
list manipulation is the prudent thing to do.

Alan Stern

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