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

On Fri, 27 Apr 2007, Linus Torvalds wrote:

> On Sat, 28 Apr 2007, Rafael J. Wysocki wrote:
>>
>>> It's doubly bad, because that idiocy has also infected s2ram. Again,
>>> another thing that really makes no sense at all - and we do it not just
>>> for snapshotting, but for s2ram too. Can you tell me *why*?
>>
>> Why we freeze tasks at all or why we freeze kernel threads?
>
> In many ways, "at all".
>
> I _do_ realize the IO request queue issues, and that we cannot actually do
> s2ram with some devices in the middle of a DMA. So we want to be able to
> avoid *that*, there's no question about that. And I suspect that stopping
> user threads and then waiting for a sync is practically one of the easier
> ways to do so.
>
> So in practice, the "at all" may become a "why freeze kernel threads?" and
> freezing user threads I don't find really objectionable.

there was a thread last week (or so) about splitting up the process list, one 
list for normal user processes, one for kernel threads, and one for dead 
processes waiting to be reaped.

it almost sounds like what you want to do is to act as if the normal user 
threads weren't there for a short time (while you make the snapshot) and then 
recover them to continue and save 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ