From: Al Viro <viro-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
To: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
Cc: Eric Biggers <ebiggers-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Tetsuo Handa
<penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>,
David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org,
tomoyo-dev-en-5NWGOfrQmneRv+LV9MX5uooqe+aC9MnS@public.gmane.org,
Paul Moore <paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org>,
Miklos Szeredi <miklos-sUDqSbJrdHQHWmgEVkV9KA@public.gmane.org>,
Stephen Smalley <sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org>,
fenghua.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
apparmor-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org,
Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Theodore Y. Ts'o" <tytso-3s7WtUTddSA@public.gmane.org>,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
"Eric W. Biederman"
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org
Subject: Re: BUG: Mount ignores mount options
Date: Sat, 11 Aug 2018 17:51:24 +0100 [thread overview]
Message-ID: <20180811165123.GH6515@ZenIV.linux.org.uk> (raw)
In-Reply-To: <9B6E2781-484B-4C42-95F5-F900EA36CEA5-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
On Sat, Aug 11, 2018 at 09:31:29AM -0700, Andy Lutomirski wrote:
> I don’t see why we need all this fancy “do the options match” stuff. For the handful of filesystems (like NFS) that do something intelligent when multiple non-bind mount requests against the same underlying storage happen, we can keep that behavior in the new API. For other filesystems that don’t have this feature, we should simply fail the request.
> IOW I see so compelling reason to call sget() at all from the new API. The only sort-of-legit use case I can think of is mounting more than one btrfs subvolume. But even that should probably not be done by asking the kernel to separately instantiate the filesystem.
May I politely suggest the esteemed participants of that conversation
to RTFS? Yes, I know that it's less fun that talking about your
rather vague ideas of how the things (surely) work, but it just might
avoid the feats of idiocy like the above.
Andy, I don't know how to put it more plainly: read the fucking source.
Even grep would do. The same NFS you've granted (among the "handful"
of filesystems) an exception, *DOES* *CALL* *THE* *FUCKING* sget().
Yes, really. And in some obscure[1] cases (including the one mentioned
upthread) it does reuse a pre-existing superblock. For a very good
reason.
[1] such as, oh, mounting two filesystems from the same server with
default options - who would've ever thought of doing something so
perverted?
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
next prev parent reply other threads:[~2018-08-11 16:51 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-01 15:23 [PATCH 00/33] VFS: Introduce filesystem context [ver #11] David Howells
2018-08-01 15:26 ` [PATCH 20/33] kernfs, sysfs, cgroup, intel_rdt: Support fs_context " David Howells
2018-08-10 14:05 ` BUG: Mount ignores mount options Eric W. Biederman
2018-08-10 14:36 ` Andy Lutomirski
2018-08-10 15:13 ` David Howells
2018-08-10 15:17 ` Eric W. Biederman
2018-08-10 15:24 ` Al Viro
2018-08-10 15:11 ` David Howells
2018-08-10 15:39 ` Theodore Y. Ts'o
2018-08-10 15:53 ` David Howells
2018-08-10 16:14 ` Theodore Y. Ts'o
2018-08-10 20:06 ` Andy Lutomirski
2018-08-10 20:46 ` Theodore Y. Ts'o
[not found] ` <20180810221234.GC4211@magnolia>
2018-08-10 23:54 ` Theodore Y. Ts'o
[not found] ` <20180810235447.GK627-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2018-08-11 0:38 ` Darrick J. Wong
2018-08-11 1:32 ` Eric W. Biederman
2018-08-13 16:35 ` Alan Cox
2018-08-13 16:48 ` Andy Lutomirski
2018-08-13 17:29 ` Al Viro
2018-08-13 19:00 ` James Morris
2018-08-13 19:20 ` Casey Schaufler
2018-08-15 23:29 ` Serge E. Hallyn
[not found] ` <20180810161400.GA627-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2018-08-11 0:28 ` Eric W. Biederman
2018-08-10 15:55 ` Casey Schaufler
2018-08-10 16:11 ` David Howells
2018-08-10 18:00 ` Eric W. Biederman
2018-08-11 1:19 ` Eric W. Biederman
[not found] ` <87pnyphf8i.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2018-08-11 7:29 ` David Howells
2018-08-11 16:31 ` Andy Lutomirski
[not found] ` <9B6E2781-484B-4C42-95F5-F900EA36CEA5-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>
2018-08-11 16:51 ` Al Viro [this message]
2018-08-10 15:11 ` Tetsuo Handa
2018-08-10 15:16 ` Al Viro
[not found] ` <20180810151606.GA6515-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2018-08-11 1:05 ` Eric W. Biederman
[not found] ` <87pnypiufr.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2018-08-11 1:46 ` Theodore Y. Ts'o
2018-08-11 4:48 ` Eric W. Biederman
[not found] ` <8736vlo6ef.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2018-08-11 17:47 ` Casey Schaufler
2018-08-15 4:03 ` Eric W. Biederman
2018-08-11 1:58 ` Al Viro
2018-08-11 2:17 ` Al Viro
2018-08-11 4:43 ` Eric W. Biederman
2018-08-13 12:54 ` Miklos Szeredi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180811165123.GH6515@ZenIV.linux.org.uk \
--to=viro-3bdd1+5odreifsdqtta3olvcufugdwfn@public.gmane.org \
--cc=apparmor-nLRlyDuq1AZFpShjVBNYrg@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=ebiggers-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=fenghua.yu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
--cc=luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org \
--cc=miklos-sUDqSbJrdHQHWmgEVkV9KA@public.gmane.org \
--cc=paul-r2n+y4ga6xFZroRs9YW3xA@public.gmane.org \
--cc=penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org \
--cc=sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org \
--cc=selinux-+05T5uksL2qpZYMLLGbcSA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=tomoyo-dev-en-5NWGOfrQmneRv+LV9MX5uooqe+aC9MnS@public.gmane.org \
--cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=tytso-3s7WtUTddSA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).