linux-kernel - Re: [RFC][PATCH -mm 1/3] PM: Hibernation and suspend notifiers

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:	Wed, 30 May 2007 22:44:24 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Pavel Machek <pavel@....cz>
Cc:	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>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Oliver Neukum <oliver@...kum.org>
Subject: Re: [RFC][PATCH -mm 1/3] PM: Hibernation and suspend notifiers

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

Greetings,
Rafael
-
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/