LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Stefan Metzmacher <metze@samba.org>
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>,
	"David Howells" <dhowells@redhat.com>,
	"Aleksa Sarai" <cyphar@cyphar.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: Thu, 12 Mar 2020 19:37:55 +0000	[thread overview]
Message-ID: <20200312193755.GL23230@ZenIV.linux.org.uk> (raw)
In-Reply-To: <8d24e9f6-8e90-96bb-6e98-035127af0327@samba.org>

On Thu, Mar 12, 2020 at 06:11:09PM +0100, Stefan Metzmacher wrote:

> If that works safely for hardlinks and having another process doing a
> rename between openat2() and unlinkat(), we could try that.
> 
> My initial naive idea was to have one syscall instead of
> linkat2/renameat3/unlinkat2.
> 
> int xlinkat(int src_dfd, const char *src_path,
>             int dst_dfd, const char *dst_path,
>             const struct xlinkat_how *how, size_t how_size);
> 
> struct xlinkat_how {
>        __u64 src_at_flags;
>        __u64 src_resolve_flags;
>        __u64 dst_at_flags;
>        __u64 dst_resolve_flags;
>        __u64 rename_flags;
>        __s32 src_fd;
> };
> 
> With src_dfd=-1, src_path=NULL, how.src_fd = -1, this would be like
> linkat().
> With dst_dfd=-1, dst_path=NULL, it would be like unlinkat().
> Otherwise a renameat2().
>
> If how.src_fd is not -1, it would be checked to be the same path as
> specified by src_dfd and src_path.

"Checked" as in...?  And is that the same path or another link to the
same object, or...?

The idea of dumping all 3 into the same syscall looks wrong - compare
the effects of link() and rename() on the opened files, for starters,
and try to come up with documentation for all of that.  Multiplexors
tend to be very bad, in large part because they have so bloody
convoluted semantics...

  reply	other threads:[~2020-03-12 19:38 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 [this message]
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
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=20200312193755.GL23230@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).