From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konstantin Khlebnikov Subject: Re: [PATCH] nextfd(2) Date: Mon, 02 Apr 2012 12:38:25 +0400 Message-ID: <4F796581.1030302@openvz.org> References: <20120401125741.GA7484@p183.telecom.by> <4F785F1D.4020503@openvz.org> <20120402010937.38b33576@pyramind.ukuu.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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" , Cyrill Gorcunov To: Alan Cox Return-path: In-Reply-To: <20120402010937.38b33576@pyramind.ukuu.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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.