[PATCH] flock() files even with a permissive share mode.

[J. Bruce Fields]

On Thu, Feb 07, 2019 at 08:52:39PM +0100, Volker Lendecke wrote:
> On Thu, Feb 07, 2019 at 10:34:20AM -0500, J. Bruce Fields wrote:
> > Honestly I'd been hoping we could just deprecate mandatory locking
> > completely!  But if this is a priority then we should figure out how to
> > save it.
> 
> Possibly we can postpone that a bit. We lived with that forever, but
> for completeness we'll need it at some point.
> 
> > We should look at Pavel Shilovsky's patches.  He did define
> > O_DENYDELETE:
> > 
> > 	https://lwn.net/Articles/557079/
> 
> Looks interesting. We need to be able to query DENYDELETE at least on
> an open fd, or even rather at open time.

Does fcntl(fd, F_GETFL, 0) do what you want?

No, I guess you want to know if somebody else has set it.  I don't know,
I don't see a way to do that on a quick skim.

> > An NFS client can keep the delegation after it closes the file, I think
> > of it as independent of any one open.
> 
> What is a delegation then? How is this referenced in the protocol?

You get a "delegation stateid" back from the open call that grants a
delegation.  It's separate from the "open stateid" that's also returned.

When the server wants the delegation recalled, it sends the delegation
stateid to identify the delegation.  And then the client also uses that
stateid to return the delegation.

We basically only ever have one delegation per (client, file) pair.

> > Sounds vaguely like NFS delegations.  But I don't know what a lease key
> > is, or what bumping an fd means.
> 
> By "bumping up" I mean that a client opens the same file multiple
> times. fd 1 references a lease key without any caching permission. The
> same client opens the same file a second time referencing the same
> lease key, this time it gets a RW lease. As this is the same file and
> lease key, also on fd1 RW caching is allowed now. The caching
> permission exists independent of a particular file handle, but when
> all handles are closed, the lease key also vanishes. SMB1 oplocks were
> strictly attached to a particular open instance. If it was broken for
> one handle, it never came back.

When it comes to designing VFS lease/delegation/oplock interfaces, I
think we'd associate the delegation with a file description, but does
this really matter?  I think a server could implement either behavior on
top of that.

--b.