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:	Wed, 2 Nov 2011 22:00:39 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Greg KH <greg@...ah.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux PM mailing list <linux-pm@...ts.linux-foundation.org>,
	Tejun Heo <tj@...nel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	LKML <linux-kernel@...r.kernel.org>,
	Magnus Damm <magnus.damm@...il.com>,
	Kevin Hilman <khilman@...com>, linux-scsi@...r.kernel.org,
	Jesse Barnes <jbarnes@...tuousgeek.org>, stable@...nel.org,
	Ulf Hansson <Ulf.Hansson@...ricsson.com>
Subject: Re: [PATCH 4/6 v2] PM: Limit race conditions between runtime PM and
 system sleep (v2)

On Wed, Nov 2, 2011 at 9:11 PM, Greg KH <greg@...ah.com> wrote:
> On Wed, Nov 02, 2011 at 09:06:02PM +0100, Linus Walleij wrote:
>> On Wed, Nov 2, 2011 at 8:14 PM, Greg KH <greg@...ah.com> wrote:
>> > So, what specific git commits do you want to see in the 3.0-stable
>> > tree, and in what order should they be applied in?
>>
>> So to my untrained eye it looks like it should be applied like this (top to
>> bottom) using the reverse commit order from the mainline kernel:
>>
>> e529192 PM: Introduce generic "noirq" callback routines for subsystems (v2)
>> 455716e PM / Runtime: Update documentation of interactions with system sleep
>> 1e2ef05 PM: Limit race conditions between runtime PM and system sleep (v2)
>> f3393b6 PM / Runtime: Add new helper function: pm_runtime_status_suspended()
>>
>> So (2) documents the problem, (3) fixes it, whereas (1) and (4) makes
>> it possible
>> to write proper _noirq() code that does not race, IIRC.
>
> But, after this, it's just adding new infrastructure that drivers will
> then be able to use.  As I'm not adding new drivers to 3.0, there will
> not be any users of this code, so why add it in the first place?  It
> doesn't look like this follows the rules of the stable kernel tree at
> all, does it?

We'll have to get some feedback from Rafael, but the way I percieved
it, the patch (2) fixes a very real race, then fixing that makes it
necessary for drivers using runtime_pm to do things differently to
be on the safe side. But none were really fixed when first merging
it.

So on second thought you probably only want patch (2)
"PM: Limit race conditions between runtime PM and system sleep (v2)"
for stable.

Yours,
Linus Walleij
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ