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

Tue Dec 8 13:07:33 MST 2009

Steven,

   LockViolationDelayOffset is the  file offset beyond which locks are always issued as delayed locks.  Default value is 0xEF000000.  Please let us know if you have any more questions.

Thanks!

Hongwei

From: Steven Danneman [mailto:steven.danneman at isilon.com]
Sent: Monday, December 07, 2009 9:03 PM
To: Hongwei Sun; cifs-protocol at samba.org; pfif at tridgell.net
Subject: RE: SMBv1 LockAndX return status on lock conflict

Hey Hongwei,

That's very interesting and indeed explains the behavior I've seen.

I can understand the motivation for delaying a small timeout for locks that the server knows are already held.  However, the "Offset >= LockViolationDelayOffset" is strange to me.  I don't understand the usefulness of that condition.

Perhaps this is an Office specific feature, since Office applications take small byte range locks past the end of file range as a primitive IPC mechanism.

Can you tell me what the value of LockViolationDelayOffset is?  The smbtorture testing seems to indicate it is Offset > 0xEF000000.

Thanks for your help.  I certainly wouldn't have figured these semantics out on my own.

-Steven

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

Hi, Steven,

        For the error returned when a byte range lock conflicts with an existing lock in SMB,  the logic is as follows:    If a lock request is above a configured offset, or if a lock request matches a previously failed lock offset, it will change it from "fail immediately" with timeout of 0 to timeout of 250 ms on operation issue.  The result is that the lock will be pending  for 250ms waiting for lock availability, and if it does not retrieve it, it returns a different error (STATUS_FILE_LOCK_CONFLICT).

      Pseudo code of above logic should be something as below:

If (FailImmediately)     // Timeout = 0

                If Offset == Open.LastFailedLockOffset OR Offset >= LockViolationDelayOffset

                                Set Timeout = LockViolationDelay  // within 250 milliseconds
                End If

End If

If Timeout = 0 and Lock Not Acquired

                Set LockViolationDelayOffset = (Offset of lock attempt)

                return STATUS_LOCK_NOT_GRANTED

Else If Timeout > 0 and Lock Not Acquired after Timeout

                return STATUS_FILE_LOCK_CONFLICT

Else
                return STATUS_SUCCESS

End If.

     With the logic above, you can easily explain what shows in your network trace.    We will add the logic to the SMB protocol document.   Please let  us know if you have further questions regarding this behavior.

Thanks!

--------------------------------------------------------------------
Hongwei  Sun - Sr. Support Escalation Engineer
DSC Protocol  Team, Microsoft
hongweis at microsoft.com<mailto:hongweis at microsoft.com>
Tel:  469-7757027 x 57027
---------------------------------------------------------------------

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<http://www.isilon.com>

[cid:image001.gif at 01C81005.1792D9C0]   How breakthroughs begin. (tm)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20091208/61639c30/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 4773 bytes
Desc: image001.gif
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20091208/61639c30/attachment-0001.gif>