Thread (5 messages) flat view 5 messages, 4 authors, 2018-08-13

Re: BUG: Mount ignores mount options

From: Al Viro <viro@ZenIV.linux.org.uk>
Date: 2018-08-11 04:49:51
Also in: cgroups, linux-fsdevel, linux-security-module, lkml, selinux

On Sat, Aug 11, 2018 at 02:58:15AM +0100, Al Viro wrote:
On Fri, Aug 10, 2018 at 08:05:44PM -0500, Eric W. Biederman wrote:
quoted
All I proposed was that we distinguish between a first mount and an
additional mount so that userspace knows the options will be ignored.
For pity sake, just what does it take to explain to you that your
notions of "first mount" and "additional mount" ARE HEAVILY FS-DEPENDENT
and may depend upon the pieces of state userland (especially in container)
simply does not have?

One more time, slowly:

mount -t nfs4 wank.example.org:/foo/bar /mnt/a
mount -t nfs4 wank.example.org:/baz/barf /mnt/b

yield the same superblock.  Is anyone who mounts something over NFS
required to know if anybody else has mounted something from the same
server, and if so how the hell are they supposed to find that out,
so that they could decide whether they are creating the "first" or
"additional" mount, whatever that might mean in this situation?

And how, kernel-side, is that supposed to be handled by generic code
of any description?  

While we are at it,
mount -t nfs4 wank.example.org:/foo/bar -o wsize=16384 /mnt/c
is *NOT* the same superblock as the previous two.
s/as the previous two/as in the previous two cases/, that is - the first two
examples yield one superblock, this one - another.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help