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: <4EDD019E.9010009@linux.vnet.ibm.com>
Date:	Mon, 05 Dec 2011 23:08:38 +0530
From:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To:	Tejun Heo <tj@...nel.org>
CC:	rjw@...k.pl, pavel@....cz, len.brown@...el.com,
	ebiederm@...ssion.com, rdunlap@...otime.net,
	linux-doc@...r.kernel.org, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH 3/3] PM / Docs: Recommend the use of [un]lock_system_sleep()
 over mutex_[un]lock(&pm_mutex)

On 12/05/2011 10:45 PM, Tejun Heo wrote:

> Hello,
> 
> On Mon, Dec 05, 2011 at 01:33:42AM +0530, Srivatsa S. Bhat wrote:
>> Update the documentation to explain the perils of directly using
>> mutex_[un]lock(&pm_mutex) and recommend the usage of the safe
>> APIs [un]lock_system_sleep() instead.
> 
> Maybe just make it pm internal?
> 


Sorry, I didn't get what you meant here. Are you talking about what
needs to be added/changed in the documentation or, are you referring
to the code itself and are saying that we must make these APIs
internal to the PM alone?

If it is the latter, please note that memory hotplug is one of the
outside-of-PM user of these APIs, and hence we really can't make
these APIs internal to the PM alone without substantially needing to
change the memory hotplug code to mutually exclude itself from PM
somehow without using these APIs.
And moreover, since these APIs avoid task freezing failures when
some out-of-PM user like memory hotplug code uses them, I don't see
much benefit by making them internal to the PM. IOW, I don't see
much use left of them, if we do that.

IMHO, we should leave these APIs as they are, until we have a better
solution for out-of-PM users to mutex themselves from PM. (For one,
currently it is not always possible to hook onto PM notifiers to
achieve that, in which case these APIs will come in handy, and these
aren't that ugly anyway, so no harm using them when necessary.)

Regards,
Srivatsa S. Bhat

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