Re: bugs with ckpt-v15-dev

[Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>]

Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
>>
>> Matt Helsley wrote:
>>> On Mon, May 18, 2009 at 06:21:22PM -0500, Nathan Lynch wrote:
>>>> Matt Helsley <matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
>>>>
>>>>> On Mon, May 18, 2009 at 04:36:11PM -0500, Nathan Lynch wrote:
>>>>>> [1] Should CONFIG_CHECKPOINT depend on CONFIG_CGROUPS and/or
>>>>>> CONFIG_CGROUPS_FREEZER?  We require tasks to be put in frozen state
>>>>>> before checkpoint, is there any mechanism apart from
>>>>>> cgroup/freezer.state to do this?
>>>>> Have you tried sending all of the tasks SIGSTOP? It won't 100% freeze
>>>>> the tasks -- they'd still be capable of responding to some signals
>>>>> (CONT, TERM..). Also they'd presumably be placed in the stopped state
>>>>> upon restart so a SIGCONT will be needed. In the case of bash, at
>>>>> least, that will technically change what happens upon restart. My
>>>>> guess is that in many cases it won't matter but there are some where
>>>>> it will.
>>>> Hmm, I'm having trouble understanding your suggestion.  The current
>>>> checkpoint implementation requires non-self tasks to be frozen (p->flags
>>>> & PF_FROZEN), which is not equivalent to stopped state (task->state &
>>>> __TASK_STOPPED).  That is, it would refuse to checkpoint tasks in
>>>> stopped state.  See may_checkpoint_task().
>>> Oops. You're right. That would require changing may_checkpoint_task() to include
>>> __TASK_STOPPED -- not something we'd want in the final code. I had assumed
>>> you wanted to try a different mechanism for debugging purposes.
>>>
>> Allowing checkpoint of stopped tasks is actually not such a bad
>> idea, IMHO.
> 
> Well, it might be bad for the same reason that Matt is pursuing the
> CHECKPOINTING freezer state:  the task might get kicked alive in
> the middle of the checkpoint.

Yes, that was my concern and I try to make the code safe with regard
to such behavior. And if that is achieved, then at worst the checkpoint
will either fail or yield meaningless results. On the other hand, it
can allow c/r without requiring cgroups/freezer, with some additional
restrictions.

> 
> So it might be ok so long as we still move the task to CHECKPOINTING
> state.  But I'm just not sure it's worth worrying about.

Probably not at the moment, except for "lowering the barrier" for
people to try it out.

Oren.