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

Powered by blists - more mailing lists