Re: [LSF/MM/BPF TOPIC] Allowing linkat() to replace the destination

From: Trond Myklebust <trondmy@hammerspace.com>
To: "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>
Cc: "hch@lst.de" <hch@lst.de>,
	"osandov@osandov.com" <osandov@osandov.com>,
	"miklos@szeredi.hu" <miklos@szeredi.hu>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"amir73il@gmail.com" <amir73il@gmail.com>,
	"dhowells@redhat.com" <dhowells@redhat.com>,
	"lsf-pc@lists.linux-foundation.org" 
	<lsf-pc@lists.linux-foundation.org>
Subject: Re: [LSF/MM/BPF TOPIC] Allowing linkat() to replace the destination
Date: Fri, 17 Jan 2020 16:12:28 +0000	[thread overview]
Message-ID: <9bfe61643b676d27abd5e3d7f8ca8ac907fbf65e.camel@hammerspace.com> (raw)
In-Reply-To: <20200117154657.GK8904@ZenIV.linux.org.uk>

On Fri, 2020-01-17 at 15:46 +0000, Al Viro wrote:
> On Fri, Jan 17, 2020 at 02:33:01PM +0000, Trond Myklebust wrote:
> > On Fri, 2020-01-17 at 12:49 +0000, David Howells wrote:
> > > It may be worth a discussion of whether linkat() could be given a
> > > flag to
> > > allow the destination to be replaced or if a new syscall should
> > > be
> > > made for
> > > this - or whether it should be disallowed entirely.
> > > 
> > > A set of patches has been posted by Omar Sandoval that makes this
> > > possible:
> > > 
> > >     
> > > https://lore.kernel.org/linux-fsdevel/cover.1524549513.git.osandov@fb.com/
> > > 
> > > though it only includes filesystem support for btrfs.
> > > 
> > > This could be useful for cachefiles:
> > > 
> > > 	
> > > https://lore.kernel.org/linux-fsdevel/3326.1579019665@warthog.procyon.org.uk/
> > > 
> > > and overlayfs.
> > > 
> > 
> > That seems to me like a "just go ahead and do it if you can justify
> > it"
> > kind of thing. It has plenty of precedent, and fits easily into the
> > existing syscall, so why do we need a face-to-face discussion?
> 
> Unfortunately, it does *not* fit easily.  And IMO that's linux-abi
> fodder more
> than anything else.  The problem is in coming up with sane semantics
> - there's
> a plenty of corner cases with that one.  What to do when destination
> is
> a dangling symlink, for example?  Or has something mounted on it (no,
> saying
> "we'll just reject directories" is not enough).  What should happen
> when
> destination is already a hardlink to the same object?
> 
> It's less of a horror than rename() would've been, but that's not
> saying
> much.

We already have precedents for all of that when handling bog-standard
open(O_CREAT) (which creates the first link to the file). Yes, there is
the question of choosing whether to implement O_NOFOLLOW semantics or
not, but that should be dictated by the requirements of the use case.

As for the "hard link on top of itself", that case is already well
defined by POSIX to be a null op IIRC.

What in the proposal is requiring new semantics beyond these precedents
already set by open() and link() itself?

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com