LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: "Stefan Metzmacher" <metze@samba.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"David Howells" <dhowells@redhat.com>,
	"Ian Kent" <raven@themaw.net>,
	"Miklos Szeredi" <mszeredi@redhat.com>,
	"Christian Brauner" <christian@brauner.io>,
	"Jann Horn" <jannh@google.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	"Karel Zak" <kzak@redhat.com>,
	jlayton@redhat.com, "Linux API" <linux-api@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	"LSM List" <linux-security-module@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Jeremy Allison" <jra@samba.org>, "Ralph Böhme" <slow@samba.org>,
	"Volker Lendecke" <vl@sernet.de>
Subject: Re: [PATCH 01/14] VFS: Add additional RESOLVE_* flags [ver #18]
Date: Fri, 13 Mar 2020 18:28:44 +0000	[thread overview]
Message-ID: <20200313182844.GO23230@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200313095901.tdv4vl7envypgqfz@yavin>

On Fri, Mar 13, 2020 at 08:59:01PM +1100, Aleksa Sarai wrote:
> On 2020-03-12, Stefan Metzmacher <metze@samba.org> wrote:
> > Am 12.03.20 um 17:24 schrieb Linus Torvalds:
> > > But yes, if we have a major package like samba use it, then by all
> > > means let's add linkat2(). How many things are we talking about? We
> > > have a number of system calls that do *not* take flags, but do do
> > > pathname walking. I'm thinking things like "mkdirat()"?)
> > 
> > I haven't looked them up in detail yet.
> > Jeremy can you provide a list?
> > 
> > Do you think we could route some of them like mkdirat() and mknodat()
> > via openat2() instead of creating new syscalls?
> 
> I have heard some folks asking for a way to create a directory and get a
> handle to it atomically -- so arguably this is something that could be
> inside openat2()'s feature set (O_MKDIR?). But I'm not sure how popular
> of an idea this is.

For fuck sake, *NO*!

We don't need any more multiplexors from hell.  mkdir() and open() have
deeply different interpretation of pathnames (and anyone who asks for
e.g. traversals of dangling symlinks on mkdir() is insane).  Don't try to
mix those; even O_TMPFILE had been a mistake.

Folks, we'd paid very dearly for the atomic_open() merge.  We are _still_
paying for it - and keep finding bugs induced by the convoluted horrors
in that thing (see yesterday pull from vfs.git#fixes for the latest crop).
I hope to get into more or less sane shape (part - this cycle, with
followups in the next one), but the last thing we need is more complexity
in the area.

Keep the semantics simple and regular; corner cases _suck_.  "Infinitely
extensible (without review)" is no virtue.  And having nowhere to hide
very special flags for very special kludges is a bloody good thing.

Every fucking time we had a multiplexed syscall, it had been a massive
source of trouble.  IF it has a uniform semantics - fine; we don't need
arseloads of read_this(2)/read_that(2).  But when you need pages upon
pages to describe the subtle differences in the interpretation of
its arguments, you have already lost.  It will be full of corner
cases, they will get zero testing and they will rot.  Inevitably.  All
the faster for the lack of people who would be able to keep all of that
in head.

We do have a mechanism for multiplexing; on amd64 it lives in do_syscall_64().
We really don't need openat2() turning into another one.  Syscall table
slots are not in a short supply, and the level of review one gets from
"new syscall added" is higher than from "make fubar(2) recognize a new
member in options->union_full_of_crap if it has RESOLVE_TO_WANK_WITH_RIGHT_HAND
set in options->flags, affecting its behaviour in some odd ways".
Which is a good thing, damnit.

  parent reply	other threads:[~2020-03-13 18:33 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-09 14:00 [PATCH 00/14] VFS: Filesystem information " David Howells
2020-03-09 14:00 ` [PATCH 01/14] VFS: Add additional RESOLVE_* flags " David Howells
2020-03-09 20:56   ` Stefan Metzmacher
2020-03-09 21:13   ` David Howells
2020-03-10  0:55   ` Aleksa Sarai
2020-03-10  1:14     ` Linus Torvalds
2020-03-10  7:25     ` David Howells
2020-03-11 17:59       ` Linus Torvalds
2020-03-12  9:08         ` Stefan Metzmacher
2020-03-12 16:24           ` Linus Torvalds
2020-03-12 17:11             ` Stefan Metzmacher
2020-03-12 19:37               ` Al Viro
2020-03-12 21:48               ` Jeremy Allison
2020-03-13  9:59               ` Aleksa Sarai
2020-03-13 10:00                 ` Aleksa Sarai
2020-03-13 16:48                 ` Jeremy Allison
2020-03-13 18:28                 ` Al Viro [this message]
2020-03-13 18:35                   ` Jeremy Allison
2020-03-16 14:21                   ` Aleksa Sarai
2020-03-16 14:20                     ` Aleksa Sarai
2020-03-12 19:25             ` Al Viro
2020-03-12 16:56           ` David Howells
2020-03-12 18:09             ` Linus Torvalds
2020-03-13  9:53               ` Aleksa Sarai
2020-03-13  9:50         ` Aleksa Sarai
2020-03-09 14:01 ` [PATCH 02/14] fsinfo: Add fsinfo() syscall to query filesystem information " David Howells
2020-03-10  9:31   ` Christian Brauner
2020-03-10  9:32     ` [PATCH v19 01/14] fsinfo: Add fsinfo() syscall to query filesystem information Christian Brauner
2020-03-10  9:32       ` [PATCH v19 14/14] arch: wire up fsinfo syscall Christian Brauner
2020-03-09 14:01 ` [PATCH 03/14] fsinfo: Provide a bitmap of supported features [ver #18] David Howells
2020-03-09 14:01 ` [PATCH 04/14] fsinfo: Allow retrieval of superblock devname, options and stats " David Howells
2020-03-09 14:01 ` [PATCH 05/14] fsinfo: Allow fsinfo() to look up a mount object by ID " David Howells
2020-03-09 14:01 ` [PATCH 06/14] fsinfo: Add a uniquifier ID to struct mount " David Howells
2020-03-09 14:01 ` [PATCH 07/14] fsinfo: Allow mount information to be queried " David Howells
2020-03-10  9:04   ` Miklos Szeredi
2020-03-09 14:02 ` [PATCH 08/14] fsinfo: Allow the mount topology propogation flags to be retrieved " David Howells
2020-03-10  8:42   ` Christian Brauner
2020-03-09 14:02 ` [PATCH 09/14] fsinfo: Provide notification overrun handling support " David Howells
2020-03-09 14:02 ` [PATCH 10/14] fsinfo: sample: Mount listing program " David Howells
2020-03-09 14:02 ` [PATCH 11/14] fsinfo: Add API documentation " David Howells
2020-03-09 14:02 ` [PATCH 12/14] fsinfo: Add support for AFS " David Howells
2020-03-09 14:02 ` [PATCH 13/14] fsinfo: Example support for Ext4 " David Howells
2020-03-09 14:02 ` [PATCH 14/14] fsinfo: Example support for NFS " David Howells
2020-03-09 17:50 ` [PATCH 00/14] VFS: Filesystem information " Jeff Layton
2020-03-09 19:22   ` Andres Freund
2020-03-09 22:49     ` Jeff Layton
2020-03-10  0:18       ` Andres Freund
2020-03-09 20:02 ` Miklos Szeredi
2020-03-09 22:52 ` David Howells
2020-03-10  9:18   ` 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=20200313182844.GO23230@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=christian@brauner.io \
    --cc=cyphar@cyphar.com \
    --cc=darrick.wong@oracle.com \
    --cc=dhowells@redhat.com \
    --cc=jannh@google.com \
    --cc=jlayton@redhat.com \
    --cc=jra@samba.org \
    --cc=kzak@redhat.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=metze@samba.org \
    --cc=mszeredi@redhat.com \
    --cc=raven@themaw.net \
    --cc=slow@samba.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vl@sernet.de \
    --subject='Re: [PATCH 01/14] VFS: Add additional RESOLVE_* flags [ver #18]' \
    /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).