linux-kernel - Re: [PATCH 1/3] PM: Introduce new top level suspend and hibernation callbacks (rev. 8)

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: <1208206130.6958.178.camel@pasglop>
Date:	Tue, 15 Apr 2008 06:48:50 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Greg KH <greg@...ah.com>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Len Brown <lenb@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Alexey Starikovskiy <astarikovskiy@...e.de>,
	David Brownell <david-b@...bell.net>,
	Pavel Machek <pavel@....cz>, Oliver Neukum <oliver@...kum.org>,
	Nigel Cunningham <ncunningham@...a.org.au>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 1/3] PM: Introduce new top level suspend and
	hibernation callbacks (rev. 8)


On Mon, 2008-04-14 at 11:13 -0400, Alan Stern wrote:
> On Mon, 14 Apr 2008, Rafael J. Wysocki wrote:
> 
> >     "you can assume that the user space is there while ->prepare() is running,
> >     but you are supposed to prevent new children of the device from being
> >     registered from that point on _and_ you have to make sure that freezable
> >     tasks will be able to freeze after ->prepare() has run" (but why on Earth a
> >     driver writer is now required to know what's a freezable task etc.?)
> 
> This reminds me...  We're going to need a way to make certain
> activities mutually exclusive with system sleep.  The simplest example
> is loading a kernel module; init and probe routines often end up
> causing new child devices to be registered.
> 
> The most straightforward approach is to use an rwsem like the one we 
> used to have.  However I'm concerned that under some circumstances 
> there might be recursive read-locking.  (For example, the init routine 
> in a newly-loaded module decides to load yet another module.  Can this 
> actually happen?  libusual does something much like it.)
> 
> So it's quite possible we'll end up needing a mechanism that resembles 
> an rwsem but allows recursive (properly nested) read-locking.  Does 
> such a thing exist already, or would it have to be invented?

Despite what Oliver says, that's a perfect example where the module load
syscalls should return an error. Maybe something like -EAGAIN would do
tho... that might need a minor update of the module init tools so they
retry instead of failing.

Ben.


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