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

[Jeff Layton]

On Fri, 2019-02-08 at 11:32 +0100, Volker Lendecke via samba-technical
wrote:
> On Thu, Feb 07, 2019 at 04:31:10PM -0500, J. Bruce Fields wrote:
> > > > 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.
> 
> Ok, that sounds promising. Do we have a user-space API for that? Take
> such a delegation in user space and get asked if someone else wants
> it? One thing I've been looking at is fanotify. If I understand that
> correctly, you can block a file from user space. This is probably not
> sufficient if we want to pass delegations back and forth between Samba
> and NFS, but it might be a start.
> 
> Just an example scenario we'd want to cover:
> 
> SMB opens a file with exclusive delegation.
> NFS also opens that file -> SMB loses its delegation.
> SMB opens a 2nd time, attempts to get exclusive delegation again.
> 
> This kind of ping-pong of delegation needs to be covered in an API.
> 
> > When it comes to designing VFS lease/delegation/oplock interfaces, I
> > think we'd associate the delegation with a file description, but does
> 
> "file description" meaning the 32-bit fd returned from open(2)?
> 

The 32-bit number is a file _descriptor_. It points to a file
_description_. open() always gives you a new file description, but dup()
will give you a second file descriptor that points to the same file
description as the first.

Currently, we track OFD, flock locks and leases in the file description.
When it is closed, they all go away (in contrast to traditional POSIX
locks that go away on any close of a file description associated with an
inode).

> > this really matter?  I think a server could implement either behavior on
> > top of that.
> 
> Samba right now is designed to have a fd per client-requested open.
> One reason is that we do the kernel access check every time the open
> comes in. We don't share os-level fd's across different protocol-level
> open-handles. To change this we'd need a call that changes a RDONLY fd
> to a RDWR one on the fly as a start.

I could envision a new fcntl call that allowed that, but it would take
significant vfs-layer work to get it into the kernel.

-- 
Jeff Layton <jlayton at samba.org>