From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sukadev Bhattiprolu Subject: Re: [RFC][PATCH 1/4][cr]: Add uid, euid params to f_modown() Date: Wed, 12 May 2010 10:30:48 -0700 Message-ID: <20100512173048.GC11144@us.ibm.com> References: <1273617500-13653-1-git-send-email-sukadev@linux.vnet.ibm.com> <1273617500-13653-2-git-send-email-sukadev@linux.vnet.ibm.com> <20100512170513.GD19314@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Oren Laadan , Matt Helsley , serue@us.ibm.com, Containers , linux-fsdevel@vger.kernel.org To: Jamie Lokier Return-path: Received: from e6.ny.us.ibm.com ([32.97.182.146]:53042 "EHLO e6.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751508Ab0ELRZm (ORCPT ); Wed, 12 May 2010 13:25:42 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e6.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o4CHNdMH000309 for ; Wed, 12 May 2010 13:23:39 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o4CHPMo5110712 for ; Wed, 12 May 2010 13:25:22 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o4CHPLSf011622 for ; Wed, 12 May 2010 14:25:22 -0300 Content-Disposition: inline In-Reply-To: <20100512170513.GD19314@shareable.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Jamie Lokier [jamie@shareable.org] wrote: | Sukadev Bhattiprolu wrote: | > Checkpoint/restart of file-owner. | > | > Add uid, euid parameters to f_modown(). These parameters will be needed | > when restarting an application (and hence restoring the file information), | > from a checkpoint image. | | This is used to make sure I/O signals on sockets, ttys, devices and so | on are delivered to a particular process. Good point. | | If any of those signals are lost when an event happens around the same Well, signals are not lost across C/R - if they were pending at checkpoint, they will be pending on restart. | time as c/r (for example, more data arriving on a pipe, a device | becomes readable/writable, or room becoming available to write, or | urgent data on a socket), a process depending on it can get stuck - | unless the process knows that c/r happened, so it knows to call | select() on all those fds after the c/r. Real devices like ttys are still TBD from C/R perspective - so data arriving from the tty is still a problem. Applications using such devices cannot be checkpointed. But for pipes, (and sockets ?) we expect that both ends are checkpointed as a container. So before the container is frozen for checkpoint, either both the write() and SIGIO (due to new data on the pipe) both happen or neither. Sukadev