linux-kernel - Re: Back to the future.

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: <Pine.LNX.4.63.0704271638150.11000@qynat.qvtvafvgr.pbz>
Date:	Fri, 27 Apr 2007 16:50:46 -0700 (PDT)
From:	David Lang <david.lang@...italinsight.com>
To:	Nigel Cunningham <nigel@...el.suspend2.net>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Pekka J Enberg <penberg@...helsinki.fi>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Back to the future.

On Sat, 28 Apr 2007, Nigel Cunningham wrote:

> Hi.
>
> On Sat, 2007-04-28 at 01:45 +0200, Rafael J. Wysocki wrote:
>> On Saturday, 28 April 2007 01:17, Linus Torvalds wrote:
>>>
>>> On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
>>>>
>>>>> And can you name a _single_ advantage of doing so?
>>>>
>>>> Yes.  We have a lot less interdependencies to worry about during the whole
>>>> operation.
>>>
>>> That's not an advantage. That's why it has *sucked*.
>>
>> Actually, the less things happen while we're creating and saving the image,
>> the less sources of potential problems there are and by freezing the kernel
>> threads (not all of them), we cause less things to happen at that time.
>>
>> To make you happy, we could stop doing that, but what actual _advantage_
>> that would bring?
>
> A couple of other advantages to freezing other processes:
>
> 1) It makes predicting how much memory is available for making and
> saving snapshot a tractable problem. It therefore makes hibernation
> _much_ more reliable.
> 2) Racing against other processes would also make hibernation slower,
> increasing the chances of your battery running out before the save is
> complete.
> 3) It makes finding potential memory leaks in the code possible. It was
> ages ago now, but at one stage I could display a table saying exactly
> how many pages had been allocated and freed by different sections of the
> process and compare the number of free pages at the start and end of the
> cycle to ensure there were no memory leaks at all.

nobody is suggesting that you leave peocesses running while you do the snapshot, 
what is being proposed is

1. pause userspace (prevent scheduling)
2. make snapshot image of memory
3. make mounted filesystems read-only (possibly with snapshot/checkpoint)
4. unpause
5. save image (with full userspace available, including network)
6. shutdown system (throw away all userspace memory, no need to do graceful
    shutdown or nice kill signals, revert filesystem to snapshot/checkpoint if
    needed)

>>> NONE of these are valid explanations at all. You're listing totally
>>> theoretical problems, and ignoring all the _real_ problems that trying to
>>> freeze kernel threads has _caused_.
>>
>> Example, please?
>
> I agree with Rafael. Freezing processes greatly helps in ensuring we
> have a consistent image. He's right, too, in asserting that it's even
> more important for Suspend2. Freezing processes is essential to being
> able to know that those LRU pages won't change and therefore being able
> to save them separately and then reuse them for the atomic copy.

all that's needed for the snapshot is to prevent userspace from scheduling, and 
prevent media from being written to in a permanent way (writing to a LVM volume 
after invoking a snapshot doesn't count, just revert to the snapshot)

David Lang
-
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/