From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751928AbdKMH5A (ORCPT ); Mon, 13 Nov 2017 02:57:00 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:34370 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751547AbdKMH46 (ORCPT ); Mon, 13 Nov 2017 02:56:58 -0500 Date: Sun, 12 Nov 2017 23:55:37 -0800 From: Ram Pai To: "Michael Kerrisk (man-pages)" Cc: lkml , linux-man , Alexander Eder , Miklos Szeredi , "linux-fsdevel@vger.kernel.org" Subject: Re: Improving documentation of parent-ID field in /proc/PID/mountinfo Reply-To: Ram Pai References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 x-cbid: 17111307-0024-0000-0000-00001779F0B7 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008061; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000239; SDB=6.00945156; UDB=6.00476973; IPR=6.00725453; BA=6.00005688; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017988; XFM=3.00000015; UTC=2017-11-13 07:55:43 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17111307-0025-0000-0000-00004D7A90DF Message-Id: <20171113075537.GG5546@ram.oc3035372033.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-13_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711130109 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 13, 2017 at 07:02:21AM +0100, Michael Kerrisk (man-pages) wrote: > Hello Ram, > > Long ago (2.6.29) you added the /proc/PID/mountinfo file and > associated documentation in Documentation/filesystems/proc.txt. Later, > I pasted much of that documentation into the proc(5) manual page. > > That documentation says of the second field in the file: > > [[ > This file contains lines of the form: > > 36 35 98:0 /mnt1 /mnt2 rw,noatime master:1 - ext3 /dev/root rw,errors=continue > (1)(2)(3) (4) (5) (6) (7) (8) (9) (10) (11) > > (1) mount ID: unique identifier of the mount (may be reused after umount) > (2) parent ID: ID of parent (or of self for the top of the mount tree) > ... > ]] > > The last piece of the description of field (2) doesn't seem to be > correct, or is at least rather unclear. I take this to be saying that > that for the root mount point, /, field (2) will have the same value > as field (1). I never actually looked at this detail closely, but > Alexander pointed out that this is obviously not so, as one can > immediately verify: > > $ grep '/ / ' /proc/$$/mountinfo > 65 0 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,seclabel,data=order > > I dug around in the kernel source for a bit. I do not have an exact > handle on the details, but I can see roughly what is going on. > Internally, there seems to be one ("hidden") mount ID reserved to each > mount namespace, and that ID is the parent of the root mount point. > > Looking through the (4.14) kernel source, mount IDs are allocated by > mnt_alloc_id() (in fs/namespace.c), which is in turn called by > alloc_vfsmnt() which is in turn called by clone_mnt(). > > A new mount namespace is created by the kernel function copy_mnt_ns() > (in fs/namespace.c, called by create_new_namespaces() in > kernel/nsproxy.c). The copy_mnt_ns() function calls copy_tree() (in > fs/namespace.c), and copy_tree() calls clone_mnt() in *two* places. > The first of these is the call that creates the "hidden" mount ID that > becomes the parent of the root mount point. (I verified this by > instrumenting the kernel with a few printk() calls to display the > IDs.) The second place where copy_tree() calls clone_mnt() is in a > loop that replicates each of the mount points (including the root > mount point) in the source mount namespace. We used to report that mount, ones upon a time. Something has changed the behavior since then and its not reported any more, thus making it hidden. > > With these details in mind, I propose to patch the man page to read as > below. Perhaps you have some corrections or improvements to suggest > for this text? > > [[ > (2) parent ID: the ID of the parent mount. For the root > mount point, the ID shown here is a hidden mount ID > associated with the mount namespace. That ID is dis‐ > tinct from any of the IDs shown in field (1) of the > records shown in the mountinfo file, and does not > appear in field (1) in the mountinfo file in any other > mount namespace. (In the initial mount namespace, > this hidden ID has the value 0.) It captures the current semantics correctly. RP