linux-kernel - Re: [RFC][PATCH 4/4] PM: Permit registrarion of parentless devices during system suspend

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, 13 Dec 2010 22:19:06 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>
Subject: Re: [RFC][PATCH 4/4] PM: Permit registrarion of parentless devices
 during system suspend

On Tue, 14 Dec 2010, Rafael J. Wysocki wrote:

> On Monday, December 13, 2010, Alan Stern wrote:
> > On Mon, 13 Dec 2010, Rafael J. Wysocki wrote:
> > 
> > > From: Rafael J. Wysocki <rjw@...k.pl>
> > > 
> > > The registration of a new parentless device during system suspend
> > > will not lead to any complications affecting the PM core (the device
> > > will be effectively seen after the subsequent resume has completed),
> > > so remove the code used for detection of such events.
> > 
> > Actually the tests you're changing were never as strong as they should
> > have been.  Drivers are supposed to avoid registering new children
> > beneath a device as soon as the device has gone through the "prepare"
> > stage, not just after the device is suspended.  Should there be a 
> > "prepared" bitflag to help implement this stronger test?
> 
> The in_suspend flag introduced by [3/4] works like this, actually.

Not entirely, because it doesn't get set until the device has gone 
through the "suspend" stage.

> > In principle the same idea applies to parentless devices, since they
> > can be considered children of the "system device" (a fictitious node at
> > the root of the device tree).  The "system" goes into the prepared
> > state before all the real devices; that's what the transition_started
> > variable was all about.  It's nothing more than the "prepared" bitflag
> > for the "system device".
> 
> It has never worked like this, because it was cleared as early as at the
> _noirq() stage.

That was part of our lenient approach, allowing devices to be 
registered during system resume earlier than the documentation says 
they should be.

> Hmm.  It looks like I should modify [3/4] to clear the in_suspend flag earlier
> to follow the current behavior (if a device is DPM_RESUMING, registration of
> new children doesn't trigger the warning).

You could clear in_suspend at the start of device_resume.

In the end, it's a question of what are we trying to accomplish.  The
warnings catch the most egregious violations of the documented
requirements.  Is the purpose to let people know about the violations,
or is it to warn about actions that appear genuinely dangerous?

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/