linux-kernel - Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime 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]

Message-ID: <Pine.LNX.4.44L0.1509211552310.1713-100000@iolanthe.rowland.org>
Date:	Mon, 21 Sep 2015 16:02:01 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
cc:	Pavel Machek <pavel@....cz>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Octavian Purdila <octavian.purdila@...el.com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	"Tirdea, Irina" <irina.tirdea@...el.com>,
	Oliver Neukum <oneukum@...e.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Brown, Len" <len.brown@...el.com>
Subject: Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing
 runtime suspend

On Mon, 21 Sep 2015, Dmitry Torokhov wrote:

> > What happens if the "inhibit" control is turned on and the driver puts 
> > the device into runtime suspend, but then an I/O request arrives?
> > 
> > 	If the I/O request originated from userspace, it means the
> > 	user is violating the terms of the "inhibit" control.  Should
> > 	the request simply fail?
> 
> What user? User that inhibited it or user that tried to use the device?

Normally they would be the same.  But even if they aren't, someone has 
violated the kernel interface: The first user told the kernel a 
particular device wasn't going to be used, and then the second user 
tried to use it.

Of course, this issue doesn't arise for devices that merely report 
external events.

> > 	What if the I/O request originated from somewhere in the
> > 	kernel, not from the user?
> 
> I think we should treat in-kernel users as all other users.
> 
> > 
> > 	Or maybe the driver would want to carry out the request,
> > 	overriding the "inhibit" control temporarily.  Does it simply
> > 	turn off the control, meaning that the device won't go back
> > 	into runtime suspend until userspace turns the control on
> > 	again?
> > 
> > 	Or if the driver doesn't turn off the "inhibit" control, then
> > 	how does it know when it can safely put the device back into
> > 	runtime suspend?
> > 
> > Qustions like these make me think that this mechanism is best suited 
> > for a kind of device that doesn't handle I/O requests.  In other words, 
> > something that just reports events as they occur -- which is another 
> > way of describing an input device!
> 
> Or maybe IIO device. Or hwmon. Or something else. I think if we allow
> drivers (or subsystems) to opt in into this mechanism it will solve much
> of worries about disks and similar devices that indeed not very suitable
> for such mechanism.

Should the mechanism really be per-device?  Or would it be more useful 
to have a single "inhibit" setting that affected all the relevant 
devices at once?

The runtime-PM "usage" value for these devices is a little tricky to 
calculate.  It should be nonzero if there are any open files _and_ the 
device isn't "inhibited".  I don't know the best way to represent that 
kind of condition in the runtime PM framework.

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/