linux-kernel - Re: Hibernation Redesign

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: <46954212.7060105@rtr.ca>
Date:	Wed, 11 Jul 2007 16:48:18 -0400
From:	Mark Lord <lkml@....ca>
To:	Jeremy Maitin-Shepard <jbms@....edu>
Cc:	Nigel Cunningham <nigel@...el.suspend2.net>,
	Miklos Szeredi <miklos@...redi.hu>, rjw@...k.pl,
	a1426z@...ab.com, jeremy@...p.org, pavel@....cz,
	nickpiggin@...oo.com.au, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: Hibernation Redesign

Jeremy Maitin-Shepard wrote:
>>
> I'll certainly admit the kexec idea is vaporware currently, but it does
> differ in a significant way from freezer-based approaches, such that I
> don't think it should be referred to as just another implementation of a
> freezer.  Specifically, it doesn't require that the "old kernel" be in a
> "consistent" state to a greater extent than suspend to ram; it is the
> case that all of the devices must be quiesced or shut down to some
> extent, but doing this without races and deadlocks (and without the
> freezer) is certainly very, very similar to what needs to be done for
> suspend to ram, which will need to be solved anyway.  Unlike the
> existing hibernate approaches, however, it will not be necessary to use
> any of the driver infrastructure once switched to the "save image"
> kernel, and thus it will not matter what locks are held, for instance.

I really doubt that kexec(a special kernel) is going to solve anything here.
The new kernel will have to initialize, probe for devices, etc.
Which will take time.
Which will slow down hibernate to an unacceptable degree.
Right now, it (TuxOnIce) is *very* fast.
Adding 10 seconds or so for reprobing/resetting/reiniting devices
is not going to be useful.
And modifying all of the drivers to *not* do their usual probe sequence
sounds rather intrusive and is likely also a non-starter here.

Or is it?

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