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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox