linux-kernel - Re: [PATCH] PM / Runtime: Only force-resume device if it has been force-suspended

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:	Thu, 21 Apr 2016 02:30:11 +0300
From:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:	Ulf Hansson <ulf.hansson@...aro.org>
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	Kevin Hilman <khilman@...nel.org>,
	linux-renesas-soc@...r.kernel.org
Subject: Re: [PATCH] PM / Runtime: Only force-resume device if it has been force-suspended

Hello,

Reviving this old thread.

On Monday 07 Mar 2016 11:10:08 Ulf Hansson wrote:
> [...]
> 
> >> I agree, that's a better idea. Drivers shouldn't call
> >> pm_runtime_force_resume() if they haven't called
> >> pm_runtime_force_suspend(), so checking the PM use count should be fine.
> >> I'll modify the patch, test it and resubmit.
> > 
> > I gave it an unfortunately unsuccessful try. The problem I ran into is
> > that device_prepare() calls pm_runtime_get_noresume() calls
> > pm_runtime_get_noresume(), with the corresponding pm_runtime_put() call
> > being performed in device_complete(). The device power usage_count is
> > thus always non-zero in the system resume handler, so I can't base the
> > decision on that.
>
> As Alan said, let's just check against 1 instead.

I gave this a try, and unfortunately it won't work.

pm_genpd_prepare() resumes devices without increasing the usage count, which 
leads to the device always being active in pm_runtime_force_suspend(). The 
usage count will be 1 if the device was suspended prior to entering system 
suspend (due to the pm_runtime_get_noresume() call in device_prepare()) or 
higher than 1 if the device was active.

However, pm_genpd_prepare() will not resume the device if suspend_power_off is 
set. In that case the device will be suspended with a usage count of 1 in 
pm_runtime_force_suspend() or active with a usage count higher than 1.

We thus can't detect at resume time whether we have force-suspended the device 
using the usage count.

Unless someone has another clever idea I'll keep the power.is_force_suspended 
flag and protect it with power.lock.

> > I also noticed that pm_genpd_prepare() runtime-resumes the device (when
> > the power domain is in the GPD_STATE_ACTIVE state). I don't know why that
> > is, but it means that in practice my device gets runtime-resumed when
> > suspending the system while it could stay runtime-suspended in practice.
> 
> I am aware of this and it's on my TODO list of improvements of genpd,
> The issue is related to an unoptimized behaviour for how genpd deal
> with wakeups during system PM.

Looking forward to seeing patches :-)

-- 
Regards,

Laurent Pinchart