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, 2 Sep 2010 14:01:32 -0700
From:	Colin Cross <ccross@...roid.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, linux-kernel@...r.kernel.org,
	linux-pm@...ts.linux-foundation.org, Pavel Machek <pavel@....cz>,
	Len Brown <len.brown@...el.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] PM: Prevent waiting forever on asynchronous resume after abort

On Thu, Sep 2, 2010 at 1:45 PM, Alan Stern <stern@...land.harvard.edu> wrote:
> On Thu, 2 Sep 2010, Colin Cross wrote:
>
>> >> I think it would be better to change device_pm_init() and add a
>> >> complete_all().
>> >
>> > I agree.
>> That would work, and was my first solution, but it increases the
>> reliance on the completion variable being left completed between state
>> transitions, which is undocumented and unnecessary.  It seems more
>> straightforward to me to only wait on the parent if the parent is
>> suspended.
>
> How about calling complete_all() from within dpm_prepare() as well?
> Then it will get initialized properly at the beginning of every sleep
> transition.
That would work, but I still don't see why it's better.  With either
of your changes, the power.completion variable is storing state, and
not just used for notification.  However, the exact meaning of that
state is unclear, especially during the transition from an aborted
suspend to resume, and the state is duplicating power.status.  Setting
it to complete in dpm_prepare is especially confusing, because at that
point nothing is completed, it hasn't even been started.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ