Bug 737091 - mount command picks random mount point to operate on during remount
Summary: mount command picks random mount point to operate on during remount
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: 15
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-09-09 15:25 UTC by Eric Paris
Modified: 2011-10-25 03:45 UTC (History)
3 users (show)

Fixed In Version: util-linux-2.20.1-1.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-10-25 03:45:16 UTC
Type: ---

Attachments (Terms of Use)

Description Eric Paris 2011-09-09 15:25:48 UTC

[root@localhost ~]# mount -t tmpfs /mnt/tmp /mnt/tmp
[root@localhost ~]# mkdir /mnt/tmp/rw
[root@localhost ~]# mount -o bind /mnt/tmp/rw /mnt/tmp/rw
[root@localhost ~]# mount -o bind,ro,remount /mnt/tmp/
[root@localhost ~]# cat /proc/self/mountinfo | grep "/mnt/tmp"
66 22 0:56 / /mnt/tmp rw,relatime shared:10 - tmpfs /mnt/tmp rw,rootcontext=system_u:object_r:mnt_t:s0,seclabel
69 66 0:56 /rw /mnt/tmp/rw ro,relatime shared:10 - tmpfs /mnt/tmp rw,rootcontext=system_u:object_r:mnt_t:s0,seclabel

Notice I told it to make /mnt/tmp ro, but instead /mnt/tmp/rw is ro!

strace shows for the bind mount on top of itself:
mount("/mnt/tmp/rw", "/mnt/tmp/rw", 0x7f56abe3d164, MS_MGC_VAL|MS_BIND, NULL) = 0

and it shows for the remount ro:
mount("/mnt/tmp", "/mnt/tmp/rw", 0x7fd660de1164, MS_RDONLY|MS_REMOUNT|MS_RELATIME|MS_BIND, "seclabel") = 0

See how /mnt/tmp/rw magic'd itself up in there?  WTH?

mount -o bind,ro,remount /mnt/tmp /mnt/tmp

results in the right thing.  Why does mount magic up /mnt/tmp/rw?

Comment 1 Karel Zak 2011-09-10 05:16:18 UTC
If (on remount) both <source> and <target> are not specified, then we use

        for (mc = mcprev->prev; mc && mc != mc0; mc = mc->prev)
                if (streq(mc->m.mnt_dir, name) ||
                    streq(mc->m.mnt_fsname, name))
                        return mc;

and that's wrong... we need to scan whole mtab (or mountinfo) for mc->m.mnt_dir and then in another loop for mc->m.mnt_fsname. 

I'll fix it ASAP.

Note that in new (F17?) libmount based mount(8) command will be --target and --source command line options to avoid ambivalent interpretation of the dir|device command line argument.

Comment 2 Karel Zak 2011-09-13 21:02:14 UTC
Fixed by upstream commit 277a6dd53569a409e05316a7bdaed0e78e326762.

Comment 3 Fedora Update System 2011-10-20 11:48:17 UTC
util-linux-2.20.1-1.fc16 has been submitted as an update for Fedora 16.

Comment 4 Fedora Update System 2011-10-20 22:15:35 UTC
Package util-linux-2.20.1-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing util-linux-2.20.1-1.fc16'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 5 Fedora Update System 2011-10-25 03:45:16 UTC
util-linux-2.20.1-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.