| 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
| ||
|
Date: Fri, 27 Apr 2007 23:24:42 +0200 From: "Rafael J. Wysocki" <rjw@...k.pl> To: Pekka J Enberg <penberg@...helsinki.fi> Cc: Nigel Cunningham <nigel@...el.suspend2.net>, Linus Torvalds <torvalds@...ux-foundation.org>, LKML <linux-kernel@...r.kernel.org> Subject: Re: Back to the future. On Friday, 27 April 2007 08:18, Pekka J Enberg wrote: > On Fri, 27 Apr 2007, Nigel Cunningham wrote: > > COW is a possibility, but I understood (perhaps wrongly) that Linus was > > thinking of a single syscall or such like to prepare the snapshot. If > > you're going to start doing things like this, won't that mean you'd then > > have to update/redo the snapshot or somehow nullify the effect of > > anything the programs does so that doing it again after the snapshot is > > restored doesn't cause problems? > > No. The snapshot is just that. A snapshot in time. From kernel point of > view, it doesn't matter one bit what when you did it or if the state has > changed before you resume. It's up to userspace to make sure the user > doesn't do real work while the snapshot is being written to disk and > machine is shut down. Why do you think that keeping the user space frozen after 'snapshot' is a bad idea? I think that solves many of the problems you're discussing. 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/
Powered by blists - more mailing lists