On 3/2/2021 10:48 AM, Aurélien Aptel wrote:
From: Aurelien Aptel <aaptel@xxxxxxxx> Similarly to NFS, CIFS flock() locks behave differently than the standard. Document those differences. Signed-off-by: Aurelien Aptel <aaptel@xxxxxxxx> --- man2/flock.2 | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/man2/flock.2 b/man2/flock.2 index 61d4b5396..9271b8fef 100644 --- a/man2/flock.2 +++ b/man2/flock.2 @@ -239,6 +239,28 @@ see the discussion of the .I "local_lock" option in .BR nfs (5). +.SS CIFS details +CIFS mounts share similar limitations with NFS.
I'd suggest removing this sentence. It doesn't really add anything to the definition.
+.PP +In Linux kernels up to 5.4, +.BR flock () +locks files on the local system, +not over SMB. A locked file won't appear locked for other SMB clients +accessing the same share.
This is discussing the scenario where a process on the server performs an flock(), right? That's perhaps confusingly special. How about "In Linux kernels up to 5.4, flock() is not propagated over SMB. A file with such locks will not appear locked for remote clients."
+.PP +Since Linux 5.5, +.BR flock () +are emulated with SMB byte-range locks on the +entire file. Similarly to NFS, this means that +.BR fcntl (2) +and +.BR flock () +locks interact with one another over SMB. Another important +side-effect is that the locks are not advisory anymore: a write on a +locked file will always fail with +.BR EACCESS . +This difference originates from the design of locks in the SMB +protocol and cannot be worked around.
"protocol, which provides mandatory locking semantics."
.SH SEE ALSO .BR flock (1), .BR close (2),
