[cifs-protocol] SMBv1 LockAndX return status on lock conflict

[Steven Danneman]

Hello Hongwei,

 

Yes, I used the Samba4 smbtorture program to exercise this behavior.
The test that best shows the many strange permutations is
RAW-LOCK-ERRORCODE.

 

For the pcap I sent I pruned that test down to a few specific
operations.  If you run that full tests you'll see many more locking
requests.

 

-Steven

 

From: Hongwei Sun [mailto:hongweis at microsoft.com] 
Sent: Tuesday, December 01, 2009 4:13 PM
To: Steven Danneman; Interoperability Documentation Help;
cifs-protocol at samba.org; pfif at tridgell.net
Subject: RE: SMBv1 LockAndX return status on lock conflict

 

Steven,

 

   I am now working on this issue.  I am wondering what program you ran
to create the network trace attached in your e-mail.   Is it Samba
smbtorture ?   If we can duplicate the behavior, it may be easier for us
to debug it.

 

Thanks!

 

Hongwei 

 

From: Steven Danneman [mailto:steven.danneman at isilon.com] 
Sent: Wednesday, November 25, 2009 5:54 PM
To: Interoperability Documentation Help; cifs-protocol at samba.org;
pfif at tridgell.net
Subject: SMBv1 LockAndX return status on lock conflict

 

Hello,

 

When requesting a byte-range lock over SMBv1 on a range of a file which
is already locked and thus will contend, the error code returned is
inconsistent.  The first attempt to acquire a held lock will return
STATUS_LOCK_NOT_GRANTED.  Subsequent requests will return
STATUS_FILE_LOCK_CONFLICT.

 

This seems as though it may be an error in the implementation of the
SMBv1 protocol as the explanation of the two errors in MS-ERREF implies
that STATUS_LOCK_NOT_GRANTED should always be returned in this
circumstance:

 

STATUS_LOCK_NOT_GRANTED              A requested file lock cannot be
granted due to other existing locks.

STATUS_FILE_LOCK_CONFLICT               A requested read/write cannot be
granted due to a conflicting file lock.

 

And in this same scenario the SMBv2 protocol always returns
STATUS_LOCK_NOT_GRANTED.

 

I aware this is a well known issue, as the Samba torture test
demonstrating this behavior have existed for a number of years, but I
haven't found any Microsoft documentation describing the semantics of
this behavior.  I've looked in MS-CIFS, MS-SMB, MS-SMB2, and MS-FSA.

 

Furthermore, which error code is returned becomes even more complicated
when additional lock requests are interspersed.  For example the
attached pcap against a W2K8R2 server shows:

 

1) Two file handles opened to the same file 0x400b, 0x400c

2) Packet 27,28: Handle 0x400b successfully acquiring an exclusive lock
on range 100 - 110

3) Packet 29-32: Handles 0x400b and 0x400c requesting the same held
range and receiving STATUS_LOCK_NOT_GRANTED

4) Packet 33-44: Again requesting the same held range and receiving
STATUS_FILE_LOCK_CONFLICT

5) Packet 45-54: Requesting a lock on an overlapping range, 105-115, and
receiving the same pattern of errors

6) Packet 55-64: Requesting a lock on the previous range, 100-110, and
now having the response be "reset" back to STATUS_LOCK_NOT_GRANTED

 

I'd like to have some documentation of the algorithm for determining
which error to return based on the state of existing locks, or history
of previously requested locks.

 

Thanks,

Steven Danneman | Software Development Engineer
Isilon Systems    P +1-206-315-7500     F  +1-206-315-7501
www.isilon.com        

    How breakthroughs begin. (tm)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20091202/9d043e73/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 4773 bytes
Desc: image001.gif
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20091202/9d043e73/attachment.gif>