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: <200912092256.45872.rjw@sisk.pl>
Date:	Wed, 9 Dec 2009 22:56:45 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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 Wednesday 09 December 2009, Alan Stern wrote:
> On Tue, 8 Dec 2009, Rafael J. Wysocki wrote:
> 
> > > Well, one difficulty.  It arises only because we are contemplating
> > > having the PM core fire up the async tasks, rather than having the
> > > drivers' suspend routines launch them (the way your original proposal
> > > did -- the difficulty does not arise there).
> > > 
> > > Suppose A and B are unrelated devices and we need to impose the
> > > off-tree constraint that A suspends after B.  With children taking
> > > their parent's lock, the way to prevent A from suspending too soon is
> > > by having B's suspend routine acquire A's lock.
> > > 
> > > But B's suspend routine runs entirely in an async task, because that
> > > task is started by the PM core and it does the method call.  Hence by
> > > the time B's suspend routine is called, A may already have begun
> > > suspending -- it's too late to take A's lock.  To make the locking
> > > work, B would have to acquire A's lock _before_ B's async task starts.  
> > > Since the PM core is unaware of the off-tree dependency, there's no
> > > simple way to make it work.
> > 
> > Do not set async_suspend for B and instead start your own async thread
> > from its suspend callback.  The parent-children synchronization is done by the
> > core anyway (at least I'd do it that way), so the only thing you need to worry
> > about is the extra dependency.
> 
> I don't like that because it introduces "artificial" dependencies: It 
> makes B depend on all the preceding synchronous suspends, even totally 
> unrelated ones.  But yes, it would work.

Well, unfortunately, it wouldn't, because (at least in the context of my last
patch) the core would release the rwsems as soon as your suspend had
returned.  So you'd have to make your suspend wait for the async thread and
that would make it pointless.  So scratch that, it wasn't a good idea at all.

This leaves us with basically two options, where the first one is to use
rwsems in a way that you've proposed (with iterating over children), and the
second one is to use completions.  In my opinion rwsems don't give us any
advantage in this case, so I'd very much prefer to use completions.

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