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.1603121153090.12240-100000@netrider.rowland.org>
Date:	Sat, 12 Mar 2016 11:57:44 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Krzysztof Kozlowski <krzk@...nel.org>
cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	<linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] PM / runtime: Document steps for device removal

On Sat, 12 Mar 2016, Krzysztof Kozlowski wrote:

> Put a reminder that during device removal drivers should revert all PM
> runtime changes from the probe. Also add a note that
> pm_runtime_disable() won't wait for pending suspend requests if
> autosuspend is not disabled before.
> 
> Signed-off-by: Krzysztof Kozlowski <krzk@...nel.org>
> ---
>  Documentation/power/runtime_pm.txt | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
> index 7328cf85236c..c05e5a17a52d 100644
> --- a/Documentation/power/runtime_pm.txt
> +++ b/Documentation/power/runtime_pm.txt
> @@ -410,7 +410,8 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
>        field was previously zero, this prevents subsystem-level runtime PM
>        callbacks from being run for the device), make sure that all of the
>        pending runtime PM operations on the device are either completed or
> -      canceled; returns 1 if there was a resume request pending and it was
> +      canceled (although this depends on disabling autosuspend before
> +      calling this); returns 1 if there was a resume request pending and it was

I don't agree with this change.  All pending operations really are
either completed or cancelled, even if autosuspend is enabled.

Any strange behavior you saw after disabling runtime PM and then 
enabling it again was caused by new operations being started after you 
re-enabled runtime PM.

>        necessary to execute the subsystem-level resume callback for the device
>        to satisfy that request, otherwise 0 is returned
>  
> @@ -586,6 +587,10 @@ drivers to make their ->remove() callbacks avoid races with runtime PM directly,
>  but also it allows of more flexibility in the handling of devices during the
>  removal of their drivers.
>  
> +Drivers in ->remove() callback should undo the runtime PM changes done
> +in ->probe(). Usually this means calling pm_runtime_disable(),
> +pm_runtime_dont_use_autosuspend() etc.
> +

That's a good addition.

>  The user space can effectively disallow the driver of the device to power manage
>  it at run time by changing the value of its /sys/devices/.../power/control
>  attribute to "on", which causes pm_runtime_forbid() to be called.  In principle,

Alan Stern

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ