From: Christian Brauner <christian@brauner.io>
To: David Howells <dhowells@redhat.com>
Cc: Miklos Szeredi <mszeredi@redhat.com>,
Al Viro <viro@ZenIV.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/6] fsmount: do not use legacy MS_ flags
Date: Fri, 21 Sep 2018 17:54:56 +0200 [thread overview]
Message-ID: <20180921155455.flkf5vdrm3vgn6do@brauner.io> (raw)
In-Reply-To: <17157.1537542475@warthog.procyon.org.uk>
On Fri, Sep 21, 2018 at 04:07:55PM +0100, David Howells wrote:
> Miklos Szeredi <mszeredi@redhat.com> wrote:
>
> > What happens if we introduce new flags for fsmount(2) and are already out
> > of flags for mount(2)? I see a big mess that way.
> >
> > So let's instead start a clean new set, to be used in the new API.
If I may chime in. I think this is a really good idea.
>
> If we must. But let's not call them just M_* please. Let's call them
> MOUNT_ATTR_* or something.
>
> > The MS_RELATIME flag was accepted but ignored. Simply leave this out of
> > the new set, since "relatime" is the default.
>
> Can we make RELATIME, STRICTATIME and NOATIME an enum rather than individual
> flags?
>
> #define MOUNT_ATTR_RDONLY 0x01
> #define MOUNT_ATTR_NOSUID 0x02
> #define MOUNT_ATTR_NODEV 0x04
> #define MOUNT_ATTR_NOEXEC 0x08
> #define MOUNT_ATTR_RELATIME 0x00
> #define MOUNT_ATTR_NOATIME 0x10
> #define MOUNT_ATTR_STRICTATIME 0x20
> #define MOUNT_ATTR_ATIME_MASK 0x30
> #define MOUNT_ATTR_NODIRATIME 0x40
>
> We can also use these for a mount_setattr() syscall:
So a - maybe stupid - question I had when recently working on a patch
was how to add new mount properties in the new api.
What I would expect is that once the new mount API has landed the old
mount() syscall should not see any new features added since I take it
that we want userspace to very slowly over time have sufficient
incentive to only use the new mount API.
So from reading the patch I got the impression that superblock mount
options passed via fsconfig() are passed as strings like "ro" and are
translated into approriate objects (e.g. flags etc.) by the kernel. That
seems like a future proof mechanism to extend mount options for
userspace without having to worry about exceeding any integer types in
the future. Maybe this would make sense for non-superblock options as
well? I can see that this is less performant that checking flags and
string parsing is a thing that is not particularly nice but it would be
one option to solve the running out of flags problem.
>
> mount_setattr(int dfd, const char *path, unsigned int atflags,
> unsigned int attr_values,
> unsigned int attr_mask);
If we go with the flag arguments wouldn't it make sense to use a larger
integer type?
>
> where atflags can potentially include AT_RECURSIVE.
Very much in favor of having this operate recursively!
Christian
next prev parent reply other threads:[~2018-09-21 21:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-20 15:12 [PATCH 0/6] mount-api: fixes and cleanups Miklos Szeredi
2018-09-20 15:12 ` [PATCH 1/6] selinux: fold superblock_doinit() into only caller Miklos Szeredi
2018-09-20 15:12 ` [PATCH 2/6] vfs_submount: use SB_SUBMOUNT instead of MS_SUBMOUNT Miklos Szeredi
2018-09-20 15:12 ` [PATCH 3/6] mount: fix regression in setting "subtype" from legacy API Miklos Szeredi
2018-09-20 15:12 ` [PATCH 4/6] fsconfig: parse "subtype" param for old internal API Miklos Szeredi
2018-09-20 15:12 ` [PATCH 5/6] fsmount: do not use legacy MS_ flags Miklos Szeredi
2018-09-20 15:12 ` [PATCH 6/6] fsconfig: rename FSCONFIG_CMD_CREATE to FSCONFIG_CMD_OBTAIN Miklos Szeredi
2018-09-21 14:41 ` [PATCH 1/6] selinux: fold superblock_doinit() into only caller David Howells
2018-09-21 14:45 ` [PATCH 2/6] vfs_submount: use SB_SUBMOUNT instead of MS_SUBMOUNT David Howells
2018-09-21 14:52 ` [PATCH 3/6] mount: fix regression in setting "subtype" from legacy API David Howells
2018-09-21 14:56 ` [PATCH 4/6] fsconfig: parse "subtype" param for old internal API David Howells
2018-09-21 15:07 ` [PATCH 5/6] fsmount: do not use legacy MS_ flags David Howells
2018-09-21 15:28 ` Miklos Szeredi
2018-09-21 15:37 ` David Howells
2018-09-21 15:54 ` Christian Brauner [this message]
2018-09-21 16:52 ` David Howells
2018-09-22 13:21 ` Christian Brauner
2018-09-22 15:48 ` David Howells
2018-09-22 16:14 ` Christian Brauner
2018-09-23 22:45 ` David Howells
2018-09-23 23:01 ` Christian Brauner
2018-09-24 6:50 ` David Howells
2018-09-24 9:47 ` Christian Brauner
2018-09-24 12:37 ` David Howells
2018-09-24 13:18 ` Christian Brauner
2018-09-21 15:11 ` [PATCH 6/6] fsconfig: rename FSCONFIG_CMD_CREATE to FSCONFIG_CMD_OBTAIN David Howells
2018-09-21 15:23 ` Miklos Szeredi
2018-09-21 16:44 ` [PATCH 0/6] mount-api: fixes and cleanups David Howells
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=20180921155455.flkf5vdrm3vgn6do@brauner.io \
--to=christian@brauner.io \
--cc=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mszeredi@redhat.com \
--cc=viro@ZenIV.linux.org.uk \
/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).