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, 31 May 2007 08:24:57 +1000
From:	Nigel Cunningham <nigel@...el.suspend2.net>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Pavel Machek <pavel@....cz>,
	Alan Stern <stern@...land.harvard.edu>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Oliver Neukum <oliver@...kum.org>
Subject: Re: [RFC][PATCH -mm 1/3] PM: Hibernation and suspend notifiers

Hi.

On Wed, 2007-05-30 at 23:11 +0200, Rafael J. Wysocki wrote:
> On Wednesday, 30 May 2007 22:44, Rafael J. Wysocki wrote:
> > Hi,
> > 
> > On Wednesday, 30 May 2007 17:37, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > +Suspend notifiers
> > > > +	(C) 2007 Rafael J. Wysocki <rjw@...k.pl>, GPL
> > > > +
> > > > +There are some operations that device drivers may want to carry out in their
> > > > +.suspend() routines, but shouldn't, because they can cause the hibernation or
> > > > +suspend to fail. For example, a driver may want to allocate a substantial amount
> > > > +of memory (like 50 MB) in .suspend(), but that shouldn't be done after the
> > > > +swsusp's memory shrinker has run.
> > > > +
> > > > +Also, there may be some operations, that subsystems want to carry out before a
> > > > +hibernation/suspend or after a restore/resume, requiring the system to be fully
> > > > +functional, so the drivers' .suspend() and .resume() routines are not suitable
> > > > +for this purpose.  For example, device drivers may want to upload firmware to
> > > > +their devices after a restore from a hibernation image, but they cannot do it by
> > > > +calling request_firmware() from their .resume() routines (user land processes
> > > > +are frozen at this point).  The solution may be to load the firmware into
> > > > +memory before processes are frozen and upload it from there in the .resume()
> > > > +routine.  Of course, a hibernation notifier may be used for this purpose.
> > > > +
> > > > +The subsystems that have such needs can register suspend notifiers that will be
> > > > +called upon the following events by the suspend core:
> > > > +
> > > > +PM_PRE_FREEZE		The system is going to hibernate or suspend, tasks will
> > > > +			be frozen immediately
> > > 
> > > Hmm, looks like bad idea if we are going to remove freezer from
> > > suspend...?
> > 
> > We need PM_PRE_FREEZE anyway and it's a different question whether or not
> > it'll be used for suspend (STR) too.
> > 
> > The timing is not the best one, but so far the freezer is in the suspend code
> > path and I need to take this into account.
> >  
> > > > +PM_POST_THAW		Tasks have just been thawed after a resume or restore
> > > > +			from a hibernation image
> > > > +
> > > > +PM_HIBERNATION_PREPARE	The system is preparing for hibernation.  Tasks have
> > > > +			been frozen, memory is going to be freed and devices
> > > > +			are going to be suspended.
> > > 
> > > Is not PRE_FREEZE enough? We can allocate memory for drivers there,
> > > too...
> > 
> > Well, there is a reason for not doing this.  Namely, if the memory if freed on
> > PM_POST_HIBERNATION after the image has been created, we can use it for saving
> > the image (and speed up the saving).
> > 
> > Besides, if the freezer is dropped from the suspend code, the notifiers will be
> > useful to it anyway IMO, and PRE_FREEZE won't make sense in that case.
> > 
> > I think the rule should be: If you need to do something _before_ tasks are
> > frozen, do it in PM_PRE_FREEZE, but if you can do that after the tasks have
> > been frozen, do it on PM_HIBERNATION_PREPARE (or PM_SUSPEND_PREPARE in the
> > suspend case).
> 
> OTOH, having considered it for a while, I think that for now I can add just
> PM_PRE_FREEZE and PM_POST_THAW, as I don't have any user for the other ones.
> The other events may be added in the future if need be (along with some users).
> 
> I'll post revised patches in a new thread.

I haven't been giving this much attention, so forgive me if I'm about to
ask a silly question... which notifiers would you see the avenrun
saving/restoring using?

Regards,

Nigel

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ