From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH] [RFC] fs, proc: don't guard /proc//task//children on CONFIG_CHECKPOINT_RESTORE Date: Thu, 21 May 2015 14:47:33 -0700 Message-ID: References: <1432204221-1933-1-git-send-email-alban@endocode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <1432204221-1933-1-git-send-email-alban-973cpzSjLbNWk0Htik3J/w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Alban Crequy Cc: Cyrill Gorcunov , Oleg Nesterov , Kees Cook , Pavel Emelyanov , Serge Hallyn , KAMEZAWA Hiroyuki , Linux API , Alexander Viro , Linux FS Devel , Andrew Morton , Alban Crequy , Iago Lopez Galeiras List-Id: linux-api@vger.kernel.org On Thu, May 21, 2015 at 3:30 AM, Alban Crequy wrote: > From: Alban Crequy > > commit 818411616baf ("fs, proc: introduce > /proc//task//children entry") introduced the children entry > for checkpoint restore and the file is only available on kernels > configured with CONFIG_EXPERT and CONFIG_CHECKPOINT_RESTORE. > > This is available in most distributions (Fedora, Debian, Ubuntu, CoreOS) > because they usually enable CONFIG_EXPERT and CONFIG_CHECKPOINT_RESTORE. > But Arch does not enable CONFIG_EXPERT or CONFIG_CHECKPOINT_RESTORE. > > However, the children proc file is useful outside of checkpoint restore. > I would like to use it in rkt. The rkt process exec() another program it > does not control, and that other program will fork()+exec() a child > process. I would like to find the pid of the child process from an > external tool without iterating in /proc over all processes to find > which one has a parent pid equal to rkt. > > Since the children proc file is useful outside of checkpoint-restore, > I am removing the guard on CONFIG_CHECKPOINT_RESTORE. I sent an essentially identical patch a couple years ago, and it got some interesting comments: http://lkml.kernel.org/g/0e00e9073855c02a382d49ba1ede9c4fda3451b7.1372189875.git.luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org See also: http://lkml.kernel.org/g/5f9a6b3ab75b12f2c5ba61ea1f6f3b08e9952b55.1372280661.git.luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org --Andy