linux-kernel - Re: Duplicate inode number when mount --bind some directories to same mountpoint. (from Fedora18 to 4.10-rc3)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170112102425.GW1555@ZenIV.linux.org.uk>
Date:   Thu, 12 Jan 2017 10:24:26 +0000
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Nakajima Akira <nakajima.akira@...com.co.jp>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Duplicate inode number when mount --bind some directories to
 same mountpoint. (from Fedora18 to 4.10-rc3)

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@...ora17 home]# mkdir a b
> [root@...ora17 home]# ls -i
> 655540 a  655542 b
> 
> [root@...ora17 home]# /root/mnt.stp &
> [root@...ora17 home]# mount --bind a /mnt
> [root@...ora17 home]# alloc_vfsmnt() new_mnt:0xffff880136bdaf00
> clone_mnt() mnt:0xffff880136bdaf00 d_iname:a inode:0xffff88013081cb00
> ino:655540
> 
> [root@...ora17 home]# mount --bind b /mnt
> [root@...ora17 home]# alloc_vfsmnt() new_mnt:0xffff8801355b4f00
> clone_mnt() mnt:0xffff8801355b4f00 d_iname:b inode:0xffff88013081c790
> ino:655542
> 
> [root@...ora17 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@...ora25 home]# mkdir a b
> [root@...ora25 home]# ls -i
> 547584 a  547586 b
> 
> [root@...ora25 home]# /root/mnt.stp &
> [root@...ora25 home]# mount --bind a /mnt
> [root@...ora25 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@...ora25 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@...ora25 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?