From: Al Viro <viro@ZenIV.linux.org.uk>
To: Nakajima Akira <nakajima.akira@nttcom.co.jp>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Duplicate inode number when mount --bind some directories to same mountpoint. (from Fedora18 to 4.10-rc3)
Date: Thu, 12 Jan 2017 10:24:26 +0000 [thread overview]
Message-ID: <20170112102425.GW1555@ZenIV.linux.org.uk> (raw)
In-Reply-To: <9795d554-d236-2096-497d-e25622042d41@nttcom.co.jp>
On Thu, Jan 12, 2017 at 06:16:35PM +0900, Nakajima Akira wrote:
> Bug:
> Duplicate inode number when mount --bind some directories to same
> mountpoint. (from Fedora18 to 4.10-rc3)
> Fedora17 and earlier works correctly.
Explain, please. "Duplicate inode number" between what and what?
> And,
> Above kernel ver 3.6 (Fedora18 including 4.10-rc3) creates many structs of
> mount than ver 3.3 (Fedora17).
> Is this a correct specification?
> Looks kernel creates same many structs of mount.
alloc_vfsmnt() and clone_mnt() are internal functions, no promises of
stability had ever been given... As for the differences between these
setups... almost certainly an effect of changed shared-subtree settings.
Userland, not kernel.
> [root@fedora17 home]# mkdir a b
> [root@fedora17 home]# ls -i
> 655540 a 655542 b
>
> [root@fedora17 home]# /root/mnt.stp &
> [root@fedora17 home]# mount --bind a /mnt
> [root@fedora17 home]# alloc_vfsmnt() new_mnt:0xffff880136bdaf00
> clone_mnt() mnt:0xffff880136bdaf00 d_iname:a inode:0xffff88013081cb00
> ino:655540
>
> [root@fedora17 home]# mount --bind b /mnt
> [root@fedora17 home]# alloc_vfsmnt() new_mnt:0xffff8801355b4f00
> clone_mnt() mnt:0xffff8801355b4f00 d_iname:b inode:0xffff88013081c790
> ino:655542
>
> [root@fedora17 home]# ls -i
> 655540 a 655542 b
> Systemtap script result on Fedora25
> Kernel create many structs of mount.
> And, inode number of "a" changes to 547586 of "b".
>
>
> [root@fedora25 home]# mkdir a b
> [root@fedora25 home]# ls -i
> 547584 a 547586 b
>
> [root@fedora25 home]# /root/mnt.stp &
> [root@fedora25 home]# mount --bind a /mnt
> [root@fedora25 home]# clone_mnt() new_mnt:0xffff99e4b7cdc900
> do_mount() mnt:0xffff99e4b7cdc900 d_iname:a inode:0xffff99e4b9dcc948
> ino:547584
> clone_mnt() new_mnt:0xffff99e4b7cdcc00
> copy_tree() mnt:0xffff99e4b7cdcc00 d_iname:a inode:0xffff99e4b9dcc948
> ino:547584
> clone_mnt() new_mnt:0xffff99e4b7cdc000
> copy_tree() mnt:0xffff99e4b7cdc000 d_iname:a inode:0xffff99e4b9dcc948
> ino:547584
> clone_mnt() new_mnt:0xffff99e4b7cdc480
> copy_tree() mnt:0xffff99e4b7cdc480 d_iname:a inode:0xffff99e4b9dcc948
> ino:547584
> clone_mnt() new_mnt:0xffff99e4b7cdc180
> copy_tree() mnt:0xffff99e4b7cdc180 d_iname:a inode:0xffff99e4b9dcc948
> ino:547584
>
> [root@fedora25 home]# mount --bind b /mnt
> clone_mnt() new_mnt:0xffff99e4b7cb1480
> do_mount() mnt:0xffff99e4b7cb1480 d_iname:b inode:0xffff99e4b9dceac8
> ino:547586
> clone_mnt() new_mnt:0xffff99e4b7cb1180
> copy_tree() mnt:0xffff99e4b7cb1180 d_iname:b inode:0xffff99e4b9dceac8
> ino:547586
> clone_mnt() new_mnt:0xffff99e4b7cb1000
> copy_tree() mnt:0xffff99e4b7cb1000 d_iname:b inode:0xffff99e4b9dceac8
> ino:547586
> clone_mnt() new_mnt:0xffff99e436df9d80
> copy_tree() mnt:0xffff99e436df9d80 d_iname:b inode:0xffff99e4b9dceac8
> ino:547586
> clone_mnt() new_mnt:0xffff99e436df9600
> copy_tree() mnt:0xffff99e436df9600 d_iname:b inode:0xffff99e4b9dceac8
> ino:547586
> clone_mnt() new_mnt:0xffff99e436df9780
> copy_tree() mnt:0xffff99e436df9780 d_iname:b inode:0xffff99e4b9dceac8
> ino:547586
> clone_mnt() new_mnt:0xffff99e436df9a80
> copy_tree() mnt:0xffff99e436df9a80 d_iname:b inode:0xffff99e4b9dceac8
> ino:547586
> clone_mnt() new_mnt:0xffff99e436df9900
> copy_tree() mnt:0xffff99e436df9900 d_iname:b inode:0xffff99e4b9dceac8
> ino:547586
> clone_mnt() new_mnt:0xffff99e436df9c00
> copy_tree() mnt:0xffff99e436df9c00 d_iname:b inode:0xffff99e4b9dceac8
> ino:547586
> clone_mnt() new_mnt:0xffff99e436df9180
> copy_tree() mnt:0xffff99e436df9180 d_iname:b inode:0xffff99e4b9dceac8
> ino:547586
> clone_mnt() new_mnt:0xffff99e436df9480
> copy_tree() mnt:0xffff99e436df9480 d_iname:b inode:0xffff99e4b9dceac8
> ino:547586
>
> [root@fedora25 home]# ls -i
> 547586 a 547586 b
What I would like to see is the contents of /proc/self/mountinfo -
systemtap be damned, there is a sane interface for getting the
mount tree setup. BTW, what's in that /root/mnt.stp thing?
next prev parent reply other threads:[~2017-01-12 10:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-12 9:16 Duplicate inode number when mount --bind some directories to same mountpoint. (from Fedora18 to 4.10-rc3) Nakajima Akira
2017-01-12 10:24 ` Al Viro [this message]
2017-01-13 1:40 ` Nakajima Akira
2017-01-13 3:26 ` Al Viro
2017-01-16 1:33 ` Nakajima Akira
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170112102425.GW1555@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=nakajima.akira@nttcom.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.