Re: [PATCH v4] flock.2: add CIFS details

On 3/11/2021 12:13 PM, Aurélien Aptel wrote:

Tom Talpey [off-list ref] writes:

quoted

On 3/11/2021 5:11 AM, Aurélien Aptel wrote:

quoted

"Alejandro Colomar (man-pages)" [off-list ref] writes:

quoted

I agree with Tom.  It's much easier to read if you just say that 'nobrl'
torns off the non-locale behaviour, and acts as 5.4 and earlier kernels.
    Unless there's any subtlety that makes it different.  Is there any?

nobrl also makes fnctl() locks local.
In 5.4 and earlier kernel, flock() is local but fnctl() isn't.

quoted

BTW, you should use "semantic newlines":

Ok, I'll redo once we agree on the text.

I wonder if it's best to leave the nobrl details to the mount.cifs
manpage, and just make a reference from here.

Another advantage of putting this in a cifs.ko-specific manpage
is that it would be significantly easier to maintain. The details
of a 5.4-to-5.5 transition are going to fade over time, and the
APIs in fcntl(2)/flock(2) really aren't driving that.

I was trying to write in the same style as the NFS details just above (see
existing man page). Give basic overview of the issues.

quoted

If not, it's going to be messy... Aurélien is this correct?

cifs.ko flock()
- local in <= 5.4
- remote by default in >= 5.5
- local if nobrl in >= 5.5

cifs.ko fcntl()
- remote by default in X.Y
- local if nobrl in X.Y

Correct.

quoted

Not sure what the value(s) of X.Y actually might be.

AFAIK fcntl() was always remote by default.
And nobrl was added in 2.6.15 (15 years ago). I wouldn't bother
mentionning X.Y, it's already complex enough as it is.

quoted

It seems odd that "nobrl" means "handle locking locally, and never
send to server". I mean, there is always byte-range locking, right?

Yes the option name can be confusing. Byte-range locking is always
possible, but with "nobrl" it's local-only.

quoted

Are there any other options or configurations that alter this?

I've taken another long look at the cifs.ko and samba code. There are
many knobs that would make an accurate matrix table pretty big.

I vote for simplicity! Especially on the fcntl(2) page in question.
Totally agree on not mentioning 2.6.x in a current manpage.

* If the mount point is done on an SMB1+UNIX Extensions
   connection, locking becomes advisory. Unless
   forcemandatorylock option is passed. This will eventually be
   implemented for SMB3 posix extensions as well (I've started a
   thread on the samba-technical mailing list).

NO SMB1 discussion! Any manpage update should not add discussion of
an obsolete nonsecure deprecated protocol, and should definitely not
passively encourage its consideration.

* If cifs.ko can get guarantees (via oplocks or leases) that it is the
   only user of a file, it caches read/writes but also locking
   locally. If the lease is broke then it will send the locks.
   The levels of caching cifs.ko can do can be changed with the cache
   mount option.

I think this is relevant to some sort of smb(7) manpage, but is much
too detailed and subtle for a paragraph summary in fcntl(2).

To be more clear, my updated thinking is to mostly drop the details
in the closing sentence:

The nobrl mount option (see mount.cifs(8)) turns off  fnctl(2)
  and  flock() lock propagation to remote clients and makes flock() locks
  advisory again.

and simply state (perhaps)

  "Remote and mandatory locking semantics may vary with SMB protocol,
   mount options and server type. See mount.cifs(8) for additional
   information."

Tom.