linux-kernel - Re: [PATCH 2/3] PM / Runtime: Clear power.deferred_resume on success in rpm

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.1208151214560.1674-100000@iolanthe.rowland.org>
Date:	Wed, 15 Aug 2012 12:19:12 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Linux PM list <linux-pm@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/3] PM / Runtime: Clear power.deferred_resume on success
 in rpm_suspend()

On Tue, 14 Aug 2012, Rafael J. Wysocki wrote:

> 
> The power.deferred_resume can only be set if the runtime PM status
> of device is RPM_SUSPENDING and it should be cleared after its
> status has been changed, regardless of whether or not the runtime
> suspend has been successful.  However, it only is cleared on suspend
> failure, while it may remain set after successful suspend and is
> happily leaked to rpm_resume() executed in that case.
> 
> That shouldn't happen, so if power.deferred_resume is set in
> rpm_suspend() after the status has been changed to RPM_SUSPENDED,
> clear it before calling rpm_resume().  Then, it doesn't need to be
> cleared before changing the status to RPM_SUSPENDING any more,
> because it's always cleared after the status has been changed to
> either RPM_SUSPENDED (on success) or RPM_ACTIVE (on failure).
> 
> Signed-off-by: Rafael J. Wysocki <rjw@...k.pl>
> ---
>  drivers/base/power/runtime.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux/drivers/base/power/runtime.c
> ===================================================================
> --- linux.orig/drivers/base/power/runtime.c
> +++ linux/drivers/base/power/runtime.c
> @@ -388,7 +388,6 @@ static int rpm_suspend(struct device *de
>  		goto repeat;
>  	}
>  
> -	dev->power.deferred_resume = false;
>  	if (dev->power.no_callbacks)
>  		goto no_callback;	/* Assume success. */
>  
> @@ -440,6 +439,7 @@ static int rpm_suspend(struct device *de
>  	wake_up_all(&dev->power.wait_queue);
>  
>  	if (dev->power.deferred_resume) {
> +		dev->power.deferred_resume = false;
>  		rpm_resume(dev, 0);
>  		retval = -EAGAIN;
>  		goto out;

Basically this comes down to a matter of taste.  I tend to use a "lazy" 
approach, not initializing values until they need to contain a proper 
value (and not worrying if they contain garbage or wrong values at 
times when they won't be used).

But of course, this is fine too.  With this change, you can also
simplify one of the tests in rpm_check_suspend_allowed().

Acked-by: Alan Stern <stern@...land.harvard.edu>

--
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/