[cifs-protocol] SMB2 mixed lock & unlock requests in a single SMB_LOCK request

Wed Dec 2 17:00:25 MST 2009

Hongwei,

I see the behavior clearly specified in MS-SMB2 3.3.5.14.1.  Thanks for
your help!

-Steven

From: Hongwei Sun [mailto:hongweis at microsoft.com] 
Sent: Wednesday, December 02, 2009 3:33 PM
To: Steven Danneman; cifs-protocol at samba.org; pfif at tridgell.net
Subject: RE: SMB2 mixed lock & unlock requests in a single SMB_LOCK
request

Steven,

   I completed the investigation on the behavior described in your
e-mail.   It is a normal behavior that has been documented in the
MS-SMB2 document.  The following is the explanation:

   The  server processing  logic  is  described in details in  "3.3.5.14
Receiving an SMB2 Lock Request".       You are right that the  both
unlock and lock requests cannot be mixed in the same SMB2_LOCK request.
The server processes the Locks array in SMB2_LOCK request as either  a
series of locks  or  a series of unlocks based on if the initial
SMB2_LOCK entry has SMB2_LOCFLAG_UNLOCK  bit set or not.    Any
combination of unlocks and locks in the same SMB2_LOCK request will fail
with STATUS_ INVALID_PARAMETER.   

  As per 3.3.5.14.1, when the lock array in SMB_LOCK  is considered as a
series of unlocks,  for any SMB2_LOCK entry,  if either
SMB2_LOCKFLAG_SHARED_LOCK or SMB2_LOCKFLAG_EXCLUSIVE_LOCK is set, the
server MUST fail the request with STATUS_INVALID_PARAMETER and stop
processing further entries in the Locks array, and all successfully
processed unlock operations will not be rolled back.

     For the network traffic you mentioned,  we can see that

1)      Packet 27-28:  A single lock request succeeding on range 0-10.

ANS:   Single lock succeeded as expected.

2)      Packet 29-30:  A lock request with unlock(0-10) and lock(10-10)
failing with INVALID_PARAMETER.

        ANS:  Since the initial SMB2_LOCK in the locks array has
SMB2_LOCKFLAG_UNLOCK bit set, server MUST process the lock array as a
series of unlocks.(3.3.5.14) and  the logic in 3.3.5.14.1 will be
applied.   Because the second lock in the Locks array has
SMB2_LOCKFLAG_SHARED_LOCK set,  the server fails with
STATUS_INVALID_PARAMETER.   But the first unlock request has been
processed and will not be rolled back.   

       3) Packet 31-32:  A lock request with lock(0-10) and lock(10-10)
succeeding, showing that the previous request, though it returned an
error, succeeded in unlocking.

       ANS:   This is expected since the unlock for range (0-10)
succeeded in 2).

      If you have further questions regarding this behavior , please
let us know.

Thanks!

--------------------------------------------------------------------

Hongwei  Sun - Sr. Support Escalation Engineer

DSC Protocol  Team, Microsoft

hongweis at microsoft.com

Tel:  469-7757027 x 57027

---------------------------------------------------------------------

From: Steven Danneman [mailto:steven.danneman at isilon.com] 
Sent: Monday, November 30, 2009 5:58 PM
To: Interoperability Documentation Help; cifs-protocol at samba.org;
pfif at tridgell.net
Subject: SMB2 mixed lock & unlock requests in a single SMB_LOCK request

Hello,

I've come across another SMB2 locking issue that I can't find explicit
documentation for in MS-SMB2 (v18.0).

My first question, is whether a single SMB_LOCK request can contain both
unlock and lock requests as the LockingAndX command type in SMBv1 could?
The MS-SMB2 document hints that the answer to this question is "no" but
it doesn't seem to explicitly state it anywhere.

Section 2.2.26 states: "The SMB2 LOCK Request packet is sent by the
client to either lock or unlock portions of a file." 

This statement is ambiguous as to whether the "or" is inclusive or
exclusive.

In my testing, sending both lock and unlock requests in a single SMB2
locking request returns a STATUS_INVALID_PARAMETER.  However, if the
requests are ordered such that a unlock structure come first, the unlock
request seems to succeed.

The attached pcap, against W2K8R2 shows:

1) Packet 27-28:  A single lock request succeeding on range 0-10.

2) Packet 29-30:  A lock request with unlock(0-10) and lock(10-10)
failing with INVALID_PARAMETER.

3) Packet 31-32:  A lock request with lock(0-10) and lock(10-10)
succeeding, showing that the previous request, though it returned an
error, succeeded in unlocking.

It seems to me the server behavior should be to return
STATUS_INVALID_PARAMETER without completing any of the lock/unlock
requests when they are mixed.  Both the fact that this isn't allowed,
and the W2K8R2 behavior deviation should be documented.

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/b68425f0/attachment-0001.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/b68425f0/attachment-0001.gif>