linux-kernel - 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]

Date:	Mon, 7 Dec 2009 14:16:40 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Alan Stern <stern@...land.harvard.edu>,
	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: [GIT PULL] PM updates for 2.6.33

On Mon, 7 Dec 2009, Rafael J. Wysocki wrote:
> 
> BTW, I still don't quite understand why not to put the parent's down_write
> operation into the core.  It's not going to hurt for the "synchronous" devices
> and the "asynchronous" ones will need to do it anyway.

That's what I started out doing (see the first pseudo-code with the two 
phases). But it _does_ actually hurt.

Because it will hurt exactly for the "multiple hubs" case: if you have two 
USB hubs in parallel (and the case that Alan pointed out about a USB host 
bridge is the exact same deal), then you want to be able to suspend and 
resume those two independent hubs in parallel too.

But if you do the "down_write()" synchronously in the core, that means 
that you are also stopping the whole "traverse the tree" thing - so now 
you aren't handling the hubs in parallel even if you are handling all the 
devices _behind_ them asynchronously.

This "serialize while traversing the tree" was what I was initially trying 
to avoid with the two-phase approach, but that I realized (after writing 
the resume path) that I could avoid much better by just moving the parents 
down_write into the asynchronous path.

> Also it looks like that's something to do unconditionally for all nodes
> having children, because the parent need not know if the children do async
> operations.

True, and that was (again) the first iteration. But see above: in order to 
allow way more concurrency, you don't want to introduce the false 
dependency between the write-lock and the traversal of the tree (or, as 
Alan points out - just a list - but that doesn't really change anything) 
that is introduced by taking the lock synchronously.

So by moving the write-lock to the asynchronous work that also shuts down 
the parent, you avoid that whole unnecessary serialization. But that means 
that you can't do the lock in generic code.

Unless you want to do _all_ of the async logic in generic code and 
re-introduce the "dev->async_suspend" flag. I would be ok with that now 
that the infrastructure seems so simple.

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