From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cyrill Gorcunov Subject: Re: [PATCH] nextfd(2) Date: Mon, 2 Apr 2012 13:26:27 +0400 Message-ID: <20120402092627.GC7607@moon> References: <20120401125741.GA7484@p183.telecom.by> <4F785F1D.4020503@openvz.org> <20120402010937.38b33576@pyramind.ukuu.org.uk> <4F796581.1030302@openvz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alan Cox , Alexey Dobriyan , "akpm@linux-foundation.org" , "viro@zeniv.linux.org.uk" , "torvalds@linux-foundation.org" , "drepper@gmail.com" , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" To: Konstantin Khlebnikov Return-path: Content-Disposition: inline In-Reply-To: <4F796581.1030302@openvz.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, Apr 02, 2012 at 12:38:25PM +0400, Konstantin Khlebnikov wrote: > Alan Cox wrote: > >>Can we add "pid" argument to be able to search next fd in other task? > >>Together with sys_kcmp() this will be very useful for checkpoint/restore. > > > >That would raise all sorts of security questions unless protected, plus > >its got races. If you want to do that and you have the rights you can do > >it via procfs anyway. > > Don't worry, I just asked. =) Seems like crtools dumps fd in the target-task context, > so the current version is suitable. Kind of ;) At moment we drain fds from dumpee task context to our tool context and then dump them. Cyrill