[PATCH v2] mount: mount--move with mtab support fix

[Denys Vlasenko]

On Tuesday 22 February 2011 14:38, Rob Landley wrote:
> There is still a situation where symlinking /etc/mtab to /proc/mounts
> isn't the right thing to do?  All these years after the introduction of
> shared subtrees?
> 
> Isn't the /etc/mtab support broken legacy crap, to which you're patching
> a single weird corner case out of the 30 different ways it's broken at
> the _design_ level?


Apparently there are still cases when usage of /proc/mounts
leads to problems.


https://bugs.busybox.net/show_bug.cgi?id=2329


On "mount -o remount,ro /path", "standard" mount does:

mount("/lib", "/mnt/tmp", 0x7f5e8d55e0c0,
MS_MGC_VAL|MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = 0

Whereas busybox mount does:

mount("/dev/mapper/vg_dhcp25227-lv_root", "/mnt/tmp", 0x6e8e9a,
MS_RDONLY|MS_REMOUNT|MS_SILENT|0x200000, "seclabel,barrier=1,data=ordered") =
-1 EBUSY

No wonder it fails - MS_BIND bit is missing.

The difference comes from the fact that "standard" mount consults /etc/mtab,
sees 

/lib /mnt/tmp none rw,bind 0 0

line there, understands that it's a bind mount, and uses correct flags;
whereas busybox mount looks into /proc/mounts, sees

/dev/mapper/vg_dhcp25227-lv_root /mnt/tmp ext4 rw,seclabel,relatime,barrier=1,data=ordered 0 0

line and there is no way for it to understand that it's a bind mount
(also, it can't figure out correct 1st arg, but that may be not needed for -o remount).


What needs to be fixed here?

Will it be a correct fix to teach kernel to ignore 1st argument to
mount(arg1, dir, fstype, MS_REMOUNT|...) and to not require MS_BIND flag to be repeated
in flags on remount of bind mounts? With such a fix,
remount of bind moubnts will work without changes to /proc/mounts format.

-- 
vda