linux-kernel - Re: [RFC v6][PATCH 0/9] Kernel based checkpoint/restart

Open Source and information security mailing list archives

Date:	Wed, 15 Oct 2008 20:06:59 -0400
From:	Oren Laadan <orenl@...columbia.edu>
To:	Cedric Le Goater <clg@...ibm.com>
CC:	Dave Hansen <dave@...ux.vnet.ibm.com>, jeremy@...p.org,
	arnd@...db.de, containers@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Alexander Viro <viro@...iv.linux.org.uk>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrey Mirkin <major@...nvz.org>
Subject: Re: [RFC v6][PATCH 0/9] Kernel based checkpoint/restart

Cedric Le Goater wrote:
> Dave Hansen wrote:
>> On Mon, 2008-10-13 at 10:13 +0200, Cedric Le Goater wrote:
>>> hmm, that's rather complex, because we have to take into account the 
>>> kernel stack, no ? This is what Andrey was trying to solve in his patchset 
>>> back in September :
>>>
>>>         http://lkml.org/lkml/2008/9/3/96
>>>
>>> the restart phase simulates a clone and switch_to to (not) restore the kernel 
>>> stack. right ? 
>> Do we ever have to worry about the kernel stack if we simply say that
>> tasks have to be *in* userspace when we checkpoint them. 
> 
> at a syscall boundary for example. that would make our life easier 
> definitely. 
> 

The ideal situation is never worry about kernel stack: either we catch
the task in user space or at a syscall boundary. This is taken care of
by freezing the tasks prior to checkpoint.

The one exception (and it is a tedious one !) are states in which the
task is already frozen by definition: any ptrace blocking point where
the tracee waits for the tracer to grant permission to proceed with
its execution. Another example is in vfork(), waiting for completion.

In both cases, there will be a kernel stack and we cannot avoid it.
The bad news is that it may be a bit tedious to restart these cases.
The good news, however, is that they are very well defined locations
with well defined semantics. So upon restart all that is needed is
to emulate the expected behavior had we not been checkpointed. This,
luckily, does not require rebuilding the kernel stack, but instead
some smart glue code for a finite set of special cases.

Oren.

> C.
> 
>> If a task is
>> in an uninterruptable wait state, I'm not sure it's safe to checkpoint
>> it anyway.
> 
> _______________________________________________
> 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