[Samba] byte range lock for Write starting on Zero and negative length ( -9223372036854775808 )

[Antonio]

Às 17:53 de 21/03/24, Jeremy Allison via samba escreveu:
> On Fri, Feb 02, 2024 at 12:30:11PM +0000, Antonio via samba wrote:
>> Dear All,
>>
>> I'm sorry to bother the list with a problem that I am not sure 
>> originates in Samba.
>> File server (no domain) is serving a mix of Windows 10 and Centos 7 
>> clients, I have strange byte range locks.
>>
>> - Server is Samba 4.17.5 / Kernel 5.14.0 Rocky 9.2
>>
>> smbstatus -B gives:
>>
>> - When client is Windows 10:
>> Byte range locks:
>> Pid        dev:inode       R/W  start     size 
>> SharePath               Name
>> -------------------------------------------------------------------------------- 
>>
>> 1551641    2431:14156401:0 W    1000013752 1 /home/geral/DAT          
>> APLIC/CC/ENCOMEND.DBF
>>
>> - When client is CentOS 7 (Samba 4.10.16 / kernel 3.10.0)
>> Byte range locks:
>> Pid        dev:inode       R/W  start     size 
>> SharePath               Name
>> -------------------------------------------------------------------------------- 
>>
>> 1835914    2431:14156401:0 W    1000013752 1 /home/geral/DAT/APLIC/CC 
>> ENCOMEND.DBF
>>
>> These are correct and the expected behaviour on both cases, files are 
>> shared and the 1 byte locks for ~write~are correctly honoured.
>>
>> Problem is with new clients CentOS Stream (Samba 4.18.6 / kernel 5.14.0)
>> Byte range locks:
>> Pid        dev:inode       R/W  start     size 
>> SharePath               Name
>> -------------------------------------------------------------------------------- 
>>
>> 1832643    2431:14156401:0 R    0         -9223372036854775808 
>> /home/geral/DAT          APLIC/CC/ENCOMEND.DBF
>>
>> The file gets locked for ~read~ starting at Zero and with a strange 
>> (negative) size. No other client can access the file...
>
> This (-9223372036854775808) is just 2^64-1 unsigned. i.e. 
> 0xFFFFFFFFFFFFFFFF
>
> Which means lock from 0 until max file size.
>

Thank you Jeremy for looking at this.
I suspect the issue might come from "mount.cifs" version 7, some kind of 
overflow on the locks struct, or something around 32 -> 64bits changes...
Windows clients I tested ( XP,  7,  10 and 11) all get the correct 
locks, as does Centos 7 with mount.cifs ver 6.2-10.

In regards to:
> Looks like we're not printing out the size correctly (using a decimal
> representation).
>

I can add that while smbstatus -B gives the length of 2^64 -1 :

Pid        dev:inode       R/W  start     size SharePath               Name
--------------------------------------------------------------------------------
79543      2053:19402687:0 R    0 -9223372036854775808 
/home/antonio            INV2023.DBF

lslocks gives:

smbd[192.168.1. 79543  POSIX      WRITE 0 0                   0 /...
(undefined)        -1 OFDLCK      READ  0     0 9223372036854775806 /home...

on the same lock.
Thanks, António