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

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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.