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

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48FC86B2.8000606@fr.ibm.com>
Date:	Mon, 20 Oct 2008 15:25:06 +0200
From:	Daniel Lezcano <dlezcano@...ibm.com>
To:	Louis.Rilling@...labs.com
CC:	Dave Hansen <dave@...ux.vnet.ibm.com>,
	containers@...ts.linux-foundation.org,
	Andrey Mirkin <major@...nvz.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/9] OpenVZ kernel based checkpointing/restart

Louis Rilling wrote:
> On Fri, Oct 17, 2008 at 04:33:03PM -0700, Dave Hansen wrote:
>> On Wed, 2008-09-03 at 14:57 +0400, 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:
>> Hi Andrey,
>>
>> I'm curious what you want to happen with this patch set.  Is there
>> something specific in Oren's set that deficient which you need
>> implemented?  Are there some technical reasons you prefer this code?
> 
> To be fair, and since (IIRC) the initial intent was to start with OpenVZ's
> approach, shouldn't Oren answer the same questions with respect to Andrey's
> patchset?
> 
> I'm afraid that we are forgetting to take the best from both approaches...

I agree with Louis.

I played with Oren's patchset and tryed to port it on x86_64. I was able 
to sys_checkpoint/sys_restart but if you remove the restoring of the 
general registers, the restart still works. I am not an expert on asm, 
but my hypothesis is when we call sys_checkpoint the registers are saved 
on the stack by the syscall and when we restore the memory of the 
process, we restore the stack and the stacked registers are restored 
when exiting the sys_restart. That make me feel there is an important 
gap between external checkpoint and internal checkpoint.

Dmitry's patchset is nice too, but IMO, it goes too far from what we 
decided to do at the container mini-summit. I think there are a lot of 
design questions to be solved before going further.

IMHO we should look at Dmitry patchset and merge the external checkpoint 
code to Oren's patchset in order to checkpoint *one* process and have 
the process to restart itself. At this point, we can begin to talk about 
the restart itself, shall we have the kernel to fork the processes to be 
restarted ? shall we fork from userspace and implement some mechanism to 
have each processes to restart themselves ? etc...

--
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/