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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ