linux-kernel - RE: [PATCH 1/1] PM / Runtime: let rpm_resume fail if rpm disabled and device suspended.

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.1406191049240.1247-100000@iolanthe.rowland.org>
Date:	Thu, 19 Jun 2014 10:56:30 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Allen Yu <alleny@...dia.com>, Kevin Hilman <khilman@...com>
cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Pavel Machek <pavel@....cz>, Len Brown <len.brown@...el.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/1] PM / Runtime: let rpm_resume fail if rpm disabled
 and device suspended.

On Thu, 19 Jun 2014, Allen Yu wrote:

> So what's the exact state of device if dev->power.is_suspended flag
> is set and runtime_status is RPM_ACTIVE? Is it a state like
> "suspended but still can be accessed"?
> 
> I'm just afraid the existing code would cause a device hang if we
> allow it to be accessed even though it's suspended (at this point
> RPM_ACTIVE could be meaningless). I don't understand the original
> motivation of these code. If it's a valid case, most likely it should
> be handled in the specific device driver instead of the PM core.

You should read the Changelog for commit 6f3c77b040f (PM / Runtime:  
let rpm_resume() succeed if RPM_ACTIVE, even when disabled, v2).  It
explains why the code looks the way it does.

However, I'm starting to think the reasoning in that commit may not be
valid.  While perhaps it is okay for some I2C devices (mentioned in the
commit log), it probably isn't okay in general.

Kevin, do have any comments on this matter?  What do you think about 
making the following change to rpm_resume():

 repeat:
	if (dev->power.runtime_error)
		retval = -EINVAL;
-	else if (dev->power.disable_depth == 1 && dev->power.is_suspended
+	else if (dev->power.disable_depth > 0
	    && dev->power.runtime_status == RPM_ACTIVE)
		retval = 1;
	else if (dev->power.disable_depth > 0)

Or even:

+	else if (dev->power.disable_depth > 0 && !dev->power.is_suspended

although this would require the I2C driver you mentioned in your commit 
to change.

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/