Cedric Le Goater wrote:Dave Hansen wrote:On Mon, 2008-10-13 at 10:13 +0200, Cedric Le Goater wrote:at a syscall boundary for example. that would make our life easier definitely.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 :Do we ever have to worry about the kernel stack if we simply say that
the restart phase simulates a clone and switch_to to (not) restore the kernel stack. right ?
tasks have to be *in* userspace when we checkpoint them.
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.