Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Miklos Szeredi <mszeredi@redhat.com>
To: David Howells <dhowells@redhat.com>
Cc: viro <viro@zeniv.linux.org.uk>, Jeff Layton <jlayton@redhat.com>,
	"Eric W. Biederman" <ebiederm@redhat.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: User-visible context-mount API
Date: Tue, 16 Jan 2018 17:41:46 +0100	[thread overview]
Message-ID: <CAOssrKdn-ZhOB9V28uL-JK9zgNGJzF4cFBeyoqLLj4pADqNFVQ@mail.gmail.com> (raw)
In-Reply-To: <1643.1516117204@warthog.procyon.org.uk>

On Tue, Jan 16, 2018 at 4:40 PM, David Howells <dhowells@redhat.com> wrote:
> Miklos Szeredi <mszeredi@redhat.com> wrote:
>
>> >  (6) Adjust a mountpoint's topology flags:
>> >
>> >         mount_set_topology(int dfd, const char *path,
>> >                            unsigned int topology_flags);
>> >
>> >  (7) Reconfigure a mountpoint:
>> >
>> >         mount_reconfigure(int dfd, const char *path,
>> >                           unsigned int mount_flags);
>>
>>
>> What's the fundamental  difference between topology flags and other
>> flags?  Why two syscalls?
>
> Actually, if you look at the do_mount() function, these *are* separate
> things.  If you look at the code:
>
>         if (flags & MS_REMOUNT)
>                 retval = do_remount(&path, flags, sb_flags, mnt_flags,
>                                     data_page);
>
> ^^^ that is mount_reconfigure() and superblock reconfiguration.
>
>         else if (flags & MS_BIND)
>                 retval = do_loopback(&path, dev_name, flags & MS_REC);
>         else if (flags & (MS_SHARED | MS_PRIVATE | MS_SLAVE | MS_UNBINDABLE))
>                 retval = do_change_type(&path, flags);
>
> ^^^ that is mount_set_topology().
>
>         else if (flags & MS_MOVE)
>                 retval = do_move_mount(&path, dev_name);
>         else
>                 retval = do_new_mount(&path, type_page, sb_flags, mnt_flags,
>                                       dev_name, data_page);
>
> The mount() syscall is actually a function switch with five functions.

Right.

Still, those two (propagation and flags) are properties of the mount.
No fundamental difference in how to handle them, that I see.  Okay, we
have MS_REC handling in the propagation and not in the flags, but
that's something that might make sense for flags as well.

What's more interesting is how MS_PRIVATE + MS_REC semantics are
complete failure in the real world: the logical thing would be to mark
a mount private on the supplied mount AND propagate an umount event to
everywhere else.  But that's not what we do, we completely mess up
propagation that can result in millions of "leaked" mounts.  I've seen
multiple bug reports where this illogical behavior fooled people.  It
can be worked around, of course, but maybe we should fix this on the
new interface and allow a sane private setting.

Thanks,
Miklos


>
> David

  reply	other threads:[~2018-01-16 16:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-15 16:07 David Howells
2018-01-15 17:31 ` Eric W. Biederman
2018-01-15 17:32 ` Eric W. Biederman
2018-01-16  9:01 ` Miklos Szeredi
2018-01-16 10:10 ` David Howells
2018-01-16 10:35   ` Miklos Szeredi
2018-01-16 14:18   ` David Howells
2018-01-17 10:43   ` Karel Zak
2018-01-16 14:55 ` David Howells
2018-01-16 15:40 ` David Howells
2018-01-16 16:41   ` Miklos Szeredi [this message]
2018-01-17  4:17     ` Al Viro
2018-01-17  9:53       ` Miklos Szeredi
2018-01-17 11:06         ` Karel Zak
2018-01-18  9:48           ` Miklos Szeredi
2018-01-19  2:27           ` Al Viro
2018-01-19  6:32         ` Al Viro

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=CAOssrKdn-ZhOB9V28uL-JK9zgNGJzF4cFBeyoqLLj4pADqNFVQ@mail.gmail.com \
    --to=mszeredi@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@redhat.com \
    --cc=jlayton@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --subject='Re: User-visible context-mount API' \
    /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

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).