linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Brauner <christian.brauner@ubuntu.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: David Howells <dhowells@redhat.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-api@vger.kernel.org,
	Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Re: [PATCH 0/4] fs: add mount_setattr()
Date: Sun, 19 Jul 2020 19:55:06 +0200	[thread overview]
Message-ID: <20200719175506.fwxsb6r6pfrdhvxb@wittgenstein> (raw)
In-Reply-To: <20200719171054.GK2786714@ZenIV.linux.org.uk>

On Sun, Jul 19, 2020 at 06:10:54PM +0100, Al Viro wrote:
> On Tue, Jul 14, 2020 at 06:14:11PM +0200, Christian Brauner wrote:
> 
> > mount_setattr() can be expected to grow over time and is designed with
> > extensibility in mind. It follows the extensible syscall pattern we have
> > used with other syscalls such as openat2(), clone3(),
> > sched_{set,get}attr(), and others.
> 
> I.e. it's a likely crap insertion vector; any patches around that thing
> will require the same level of review as addition of a brand new syscall.

Which is just how we should and hopefully treat any meaningful
extension, yes. Otherwise let's just never add a flag argument to any
syscall and only have dup()- and accept()-like syscalls.

> And they will be harder to spot - consider the likely subjects for such
> patches and compare to open addition of a new syscall...

In the new revision I have dropped the atime argument because David
already plumbed setting atime into fsmount() via flags and making
userspace jump through more hoops by adding more constants seems
pointless. So the additional arguments can be moved up because we're
below the 6 syscall args limit.

Though I really want to stress that while I see the worry it is less a
technial argument but one for our review process where we should treat
extensions to syscalls as strict as syscall additions. Which yes, very
much so.

Thanks!
Christian

  reply	other threads:[~2020-07-19 17:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-14 16:14 [PATCH 0/4] fs: add mount_setattr() Christian Brauner
2020-07-14 16:14 ` [PATCH] mount_setattr.2: New manual page documenting the mount_setattr() system call Christian Brauner
2020-07-21  9:59   ` Michael Kerrisk (man-pages)
2020-07-14 16:14 ` [PATCH 1/4] namespace: take lock_mount_hash() directly when changing flags Christian Brauner
2020-07-14 16:49   ` Jann Horn
2020-07-14 16:14 ` [PATCH 2/4] namespace: only take read lock in do_reconfigure_mnt() Christian Brauner
2020-07-14 16:14 ` [PATCH 3/4] fs: add mount_setattr() Christian Brauner
2020-07-15  8:29   ` Geert Uytterhoeven
2020-07-15 11:02   ` Christian Brauner
2020-07-14 16:14 ` [PATCH 4/4] tests: add mount_setattr() selftests Christian Brauner
2020-07-19 17:10 ` [PATCH 0/4] fs: add mount_setattr() Al Viro
2020-07-19 17:55   ` Christian Brauner [this message]
2020-10-01 14:17 ` Pavel Tikhomirov

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=20200719175506.fwxsb6r6pfrdhvxb@wittgenstein \
    --to=christian.brauner@ubuntu.com \
    --cc=dhowells@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.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).