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]

Date:	Wed, 11 Jul 2007 09:16:41 -0400
From:	Jeremy Maitin-Shepard <jbms@....edu>
To:	Nigel Cunningham <nigel@...el.suspend2.net>
Cc:	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

Nigel Cunningham <nigel@...el.suspend2.net> writes:

[snip]

> No other _proper_ solutions have been proposed. Everyone who suggests removing 
> the freezer also suggests implementing it all over again. It might be sending 
> SIGSTOP to everything. It might be shifting the desk chairs around and 
> creating a completely new kernel context, but they always have the same 
> goal - stopping the existing activity, and they all come with their own 
> issues (even if they're not obvious yet because the alternatives are 
> currently vapourware to one extent or another).

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.

[snip]

-- 
Jeremy Maitin-Shepard
-
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/