Re: mount existing tmpfs mounts a new tmpfs

Re: mount existing tmpfs mounts a new tmpfs

[Phil Susi]

Ccing linux-fsdevel.  To catch up if you are just tuning in, the 
original problem is that "mount /run" mounts a new instance of tmpfs 
over top of the existing one, hiding the existing files, rather than 
reporting that it is already mounted.  The question is, is this a bug in 
mount, or the kernel?

On 6/22/2015 10:15 AM, Karel Zak wrote:
> # strace -e mount mount /boot
> mount("/dev/sda2", "/boot", "ext4", MS_MGC_VAL, NULL) = -1 EBUSY
> (Device or resource busy)

Why on earth is the kernel still returning EBUSY here?  It *does* 
support mounting the same block device multiple times these days so it 
should not be doing this.  It looks like it has some check to see if 
that device is already mounted somewhere in the current filesystem 
namespace and returns EBUSY if it is, otherwise, just bind mounts the 
existing mount if it is mounted in a different filesystem namespace. 
Not only does this check seem pointless, but it simply makes no sense at 
all for any filesystem that isn't backed by a block device, such as 
tmpfs, procfs, network filesystems, etc.

>> $ mount /tmp/proc/
>> mount: proc is already mounted or /tmp/proc busy
>>         proc is already mounted on /proc
>>         proc is already mounted on /tmp/proc
>
> strace -e mount mount -t proc none /proc
> mount("none", "/proc", "proc", MS_MGC_VAL, NULL) = -1 EBUSY (Device or
> resource busy)

Now *what* is this nonsense?  You can mount proc any time, anywhere you 
want to.  This EBUSY seems to be a special case hack that you only get 
if you try to mount procfs inside procfs.  You can mount any other fs 
over top of /proc, and you can mount /proc over top of any other fs. 
Why the one off check for mounting proc on top of proc?  And is tmpfs 
and any other virtual filesystem supposed to do this same check?

What if you really *want* to mount a new tmpfs over the old one?  The 
kernel shouldn't be denying that request ( really, same goes for proc ). 
  It therefore, should be the responsibility of mount ( single argument 
form ) to notice when you have requested mounting of an already mounted 
filesystem listed in /fstab, and it certainly should not be treating 
/etc/mtab as if it were /etc/fstab and trying to mount the same thing a 
second time; the single argument form of mount should only consult 
fstab, not mtab too.

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in

Re: mount existing tmpfs mounts a new tmpfs

[Tom Yan]

Isn't it just the same case as when you mount something else to a
mountpoint being used? Like if /dev/sda1 is already mounted to /boot,
and it has an entry in fstab, then you probably can't `mount /dev/sda1
/boot` or `mount /boot`, but you can still mount sda2 or so to /boot.
And since each tmpfs is like a new filesystem, so isn't it pretty
consistent?

Though I have no idea why wouldn't in Debian tell you it's not in
fstab. Who knows what patches have they applied.

On 23 June 2015 at 02:45, Phil Susi <psusi-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> wrote:
> Ccing linux-fsdevel.  To catch up if you are just tuning in, the original
> problem is that "mount /run" mounts a new instance of tmpfs over top of the
> existing one, hiding the existing files, rather than reporting that it is
> already mounted.  The question is, is this a bug in mount, or the kernel?
>
> On 6/22/2015 10:15 AM, Karel Zak wrote:
>>
>> # strace -e mount mount /boot
>> mount("/dev/sda2", "/boot", "ext4", MS_MGC_VAL, NULL) = -1 EBUSY
>> (Device or resource busy)
>
>
> Why on earth is the kernel still returning EBUSY here?  It *does* support
> mounting the same block device multiple times these days so it should not be
> doing this.  It looks like it has some check to see if that device is
> already mounted somewhere in the current filesystem namespace and returns
> EBUSY if it is, otherwise, just bind mounts the existing mount if it is
> mounted in a different filesystem namespace. Not only does this check seem
> pointless, but it simply makes no sense at all for any filesystem that isn't
> backed by a block device, such as tmpfs, procfs, network filesystems, etc.
>
>>> $ mount /tmp/proc/
>>> mount: proc is already mounted or /tmp/proc busy
>>>         proc is already mounted on /proc
>>>         proc is already mounted on /tmp/proc
>>
>>
>> strace -e mount mount -t proc none /proc
>> mount("none", "/proc", "proc", MS_MGC_VAL, NULL) = -1 EBUSY (Device or
>> resource busy)
>
>
> Now *what* is this nonsense?  You can mount proc any time, anywhere you want
> to.  This EBUSY seems to be a special case hack that you only get if you try
> to mount procfs inside procfs.  You can mount any other fs over top of
> /proc, and you can mount /proc over top of any other fs. Why the one off
> check for mounting proc on top of proc?  And is tmpfs and any other virtual
> filesystem supposed to do this same check?
>
> What if you really *want* to mount a new tmpfs over the old one?  The kernel
> shouldn't be denying that request ( really, same goes for proc ).  It
> therefore, should be the responsibility of mount ( single argument form ) to
> notice when you have requested mounting of an already mounted filesystem
> listed in /fstab, and it certainly should not be treating /etc/mtab as if it
> were /etc/fstab and trying to mount the same thing a second time; the single
> argument form of mount should only consult fstab, not mtab too.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux" in
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html