From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [RFC][PATCH 1/2] Track in-kernel when we expect checkpoint/restart to work Date: Fri, 10 Oct 2008 09:33:34 -0700 Message-ID: <1223656415.11830.48.camel@nimitz> References: <20081009190405.13A253CB@kernel> <1223626834.8787.8.camel@localhost.localdomain> <48EF144D.1050906@fr.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <48EF144D.1050906-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Daniel Lezcano Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Ingo Molnar , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, arnd-r2nGTMty4D4@public.gmane.org List-Id: containers.vger.kernel.org On Fri, 2008-10-10 at 10:37 +0200, Daniel Lezcano wrote: > For example, you create a socket, the process becomes uncheckpointable, > you close (via sys_close) the socket, you have to track this close to be > related to the socket which made the process uncheckpointable in order > to make the operation reversible. Challenging, yes. Not quite a nightmare, though. It's basically the same problem we have with r/o bind mounts individual users in the kernel need to check some global state. There are temporary (like the duration of the syscall) and more chronic (like your sockets) users. The hard part is making sure that everything gets properly balanced with the chronic ones. But, we did manage to accomplish that with the r/o bind mounts. I haven't seen a bug in *hours*! ;) In any case, we can worry about that later. -- Dave From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761939AbYJJQhW (ORCPT ); Fri, 10 Oct 2008 12:37:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755842AbYJJQhJ (ORCPT ); Fri, 10 Oct 2008 12:37:09 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:56951 "EHLO e6.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754859AbYJJQhI (ORCPT ); Fri, 10 Oct 2008 12:37:08 -0400 Subject: Re: [RFC][PATCH 1/2] Track in-kernel when we expect checkpoint/restart to work From: Dave Hansen To: Daniel Lezcano Cc: Greg Kurz , linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org, Ingo Molnar , arnd@arndb.de In-Reply-To: <48EF144D.1050906@fr.ibm.com> References: <20081009190405.13A253CB@kernel> <1223626834.8787.8.camel@localhost.localdomain> <48EF144D.1050906@fr.ibm.com> Content-Type: text/plain Date: Fri, 10 Oct 2008 09:33:34 -0700 Message-Id: <1223656415.11830.48.camel@nimitz> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2008-10-10 at 10:37 +0200, Daniel Lezcano wrote: > For example, you create a socket, the process becomes uncheckpointable, > you close (via sys_close) the socket, you have to track this close to be > related to the socket which made the process uncheckpointable in order > to make the operation reversible. Challenging, yes. Not quite a nightmare, though. It's basically the same problem we have with r/o bind mounts individual users in the kernel need to check some global state. There are temporary (like the duration of the syscall) and more chronic (like your sockets) users. The hard part is making sure that everything gets properly balanced with the chronic ones. But, we did manage to accomplish that with the r/o bind mounts. I haven't seen a bug in *hours*! ;) In any case, we can worry about that later. -- Dave