Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S934485AbdC3WFZ (ORCPT <rfc822;w@1wt.eu>);
        Thu, 30 Mar 2017 18:05:25 -0400
Received: from mail.linuxfoundation.org ([140.211.169.12]:36300 "EHLO
        mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S934044AbdC3WFX (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 30 Mar 2017 18:05:23 -0400
Date: Thu, 30 Mar 2017 15:05:20 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Kirill Tkhai <ktkhai@virtuozzo.com>
Cc: <agruenba@redhat.com>, <keescook@chromium.org>,
        <linux-api@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <viro@zeniv.linux.org.uk>, <oleg@redhat.com>, <paul@paul-moore.com>,
        <ebiederm@xmission.com>, <avagin@openvz.org>,
        <linux-fsdevel@vger.kernel.org>, <mtk.manpages@gmail.com>,
        <luto@amacapital.net>, <mingo@kernel.org>, <serge@hallyn.com>
Subject: Re: [PATCH RESEND 2/2] pidns: Expose task pid_ns_for_children to
 userspace
Message-Id: <20170330150520.1bdf20e599ff464bda0776b9@linux-foundation.org>
In-Reply-To: <149086967937.4388.471494976517194744.stgit@localhost.localdomain>
References: <149086931397.4388.9604947335273204415.stgit@localhost.localdomain>
        <149086967937.4388.471494976517194744.stgit@localhost.localdomain>
X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1082
Lines: 29

On Thu, 30 Mar 2017 13:27:59 +0300 Kirill Tkhai <ktkhai@virtuozzo.com> wrote:

> pid_ns_for_children set by a task is known only to the task itself,
> and it's impossible to identify it from outside.
> 
> It's a big problem for checkpoint/restore software like CRIU,
> because it can't correctly handle tasks, that do setns(CLONE_NEWPID)
> in proccess of their work.
> 
> This patch solves the problem, and it exposes pid_ns_for_children
> to ns directory in standard way with the name "pid_for_children":
> 
> ~# ls /proc/5531/ns -l | grep pid
> lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid -> pid:[4026531836]
> lrwxrwxrwx 1 root root 0 Jan 14 16:38 pid_for_children -> pid:[4026532286]
> 
> --- a/fs/proc/namespaces.c
> +++ b/fs/proc/namespaces.c
> @@ -23,6 +23,7 @@ static const struct proc_ns_operations *ns_entries[] = {
>  #endif
>  #ifdef CONFIG_PID_NS
>  	&pidns_operations,
> +	&pidns_for_children_operations,
>  #endif

This interface should be documented somewhere under Documentation/. 
But I can't immediately find where the /proc/pid/ns/ pseudo-files are
documented...