linux-kernel - Re: [PATCH 0/9] OpenVZ kernel based checkpointing/restart

Open Source and information security mailing list archives

Message-ID: <20080903141841.GA13425@us.ibm.com>
Date:	Wed, 3 Sep 2008 09:18:41 -0500
From:	"Serge E. Hallyn" <serue@...ibm.com>
To:	Cedric Le Goater <clg@...ibm.com>
Cc:	Andrey Mirkin <major@...nvz.org>,
	containers@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/9] OpenVZ kernel based checkpointing/restart

Quoting Cedric Le Goater (clg@...ibm.com):
> Andrey Mirkin wrote:
> > This patchset introduces kernel based checkpointing/restart as it is
> > implemented in OpenVZ project. This patchset has limited functionality and
> > are able to checkpoint/restart only single process. Recently Oren Laaden
> > sent another kernel based implementation of checkpoint/restart. The main
> > differences between this patchset and Oren's patchset are:
> > 
> > * In this patchset checkpointing initiated not from the process
> > (right now we do not have a container, only namespaces), Oren's patchset
> > performs checkpointing from the process context.
> > 
> > * Restart in this patchset is initiated from process, which restarts a new
> > process (in new namespaces) with saved state. Oren's patchset uses the same
> > process from which restart was initiated and restore saved state over it.
> > 
> > * Checkpoint/restart functionality in this patchset is implemented as a kernel
> > module
> 
> why ? Do we really think that C/R implementations will be so different that
> we will need C/R ops to support all of them ? I imagine that there could be 
> different models :

At the mini-summit two reasons were brought up to make it a module:

	1. So sysadmins worried about security implications can
	completely unload the module

	2. So developers can unload and reload the module while
	testing.

> 	1. brute force : dump it all and kill
> 	2. incremental
> 	3. live migration 
> 	...

Actually I don't think we expected to use different implementations for
those.

> But I see all of them really tied to the kernel internals.
> 
> The first issues I see with this direction are some EXPORT_SYMBOL() that would 
> be useless without a module.
>
> > As checkpointing is initiated not from the process which state should be saved
> > we should freeze a process before saving its state. Right now Container Freezer
> > from Matt Helsley can be used for this.
> 
> OK that's integrated and Daniel's tools :
> 
> http://lxc.cvs.sourceforge.net/lxc/
> 
> one more reason to work on integration :)
> 
> C. 
> 
> 
> > This patchset introduce only a concept how kernel based checkpointing/restart
> > can be implemented and are able to checkpoint/restart only a single process
> > with simple VMAs. 
> > 
> > I've tried to split my patchset in small patches to make review more easier.
> > _______________________________________________
> > Containers mailing list
> > Containers@...ts.linux-foundation.org
> > https://lists.linux-foundation.org/mailman/listinfo/containers
> > 
> 
> _______________________________________________
> Containers mailing list
> Containers@...ts.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
--
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/

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