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

[J. Bruce Fields]

On Wed, Feb 06, 2019 at 09:26:09PM +0100, Volker Lendecke wrote:
> On Wed, Feb 06, 2019 at 03:13:28PM -0500, J. Bruce Fields via samba-technical wrote:
> > I could help write up or compile some sort of "introduction to NFS
> > locking for SMB developers".  NFSv4 has byte-range locks, share locks,
> > and delegations, you're interested in all three?
> 
> Very much so. For a start:
> 
> brlocks == brlocks (how similar are they to Posix in NFS?)

Right.  They're the same as posix locks, so the documentation under
"Advisory record locking" in the fcntl(2) man page should all apply.
They're fully implemented and commonly used on both the client and
server side.

> Share locks == share modes (i.e. per-open locks in different modes)

I think this short section has what you need:

	https://tools.ietf.org/html/rfc7530#section-9.9

The Linux client does not use them, and knfsd implements them itself
without involving the vfs--which means they're enforced between nfs
clients, but have no effect on non-NFS users of the same filesystem
(including Samba).  I doubt they're used much.

In 2014 Pavel Shilovsky posted some patches adding support for
O_DENY{READ,WRITE,DELETE} flags, which would have given us what we need
to support these at the VFS level.  I don't recall why they weren't
merged, possibly he just ran out of time to follow up.  (Search for "Add
O_DENY* support for VFS and CIFS/NFS").

> delegations == oplocks/leases (i.e. permission to cache contents)

Yes.  This is a little more complicated.  This:

	https://tools.ietf.org/html/rfc7530#section-1.4.6

might be a good starting point.

A client may hold a read delegation or a write delegation on a file.
Delegations are given out in response to OPEN requests (in NFSv4.1+
there's also a separate operation added to request them at times other
than open).  Servers may choose not to give them out at their
discretion.  A write delegation may be held by only one client at a
time.  A read delegation conflicts with write opens, write locks, and
any operation that would change the file's metadata, including any links
pointing to the file (so, link, unlink, rename, setattr, etc.), when
those operations come from a different client.  A write delegation
conflicts with all those operations and also with read opens and locks
from other clients.  On conflict, the conflicting operation is blocked
while the delegation-holder is notified and given some time
(configurable, typically about a minute) to replay any cached data,
opens, or locks to the server and return the delegation.

Our client currently implements read and write delegations, but the
server only supports read delegations for now.  (I'm working on
implementing write delegations.)

--b.