none
bizarre SMB2 locking behaviour RRS feed

  • Question

  • I've noticed that Vista as a server for SMB2 does an implicit unlock for failed locking requests. That seems very strange to me, as failed requests do not normally cause changes in the state of the server.

    An example of this is:

      - lock 10 bytes - STATUS_OK
      - lock 10 bytes - STATUS_LOCK_NOT_GRANTED
      - lock 10 bytes - STATUS_OK

    what seems to happen is the 2nd lock request (which fails as it collides with the first) unlocks the range, and then the 3rd lock request succeeds.

    Can anyone explain what is going on? Is it deliberate?

    Cheers, Tridge

    PS: example in capture at http://samba.org/~tridge/smb2_auto_unlock.cap


    Thursday, May 22, 2008 2:12 AM

Answers

  •  

    Tridge,

     

      Based on the information you provided, we confirmed that this is a problem in  our  implementation that should be fixed.  We will report this problem to the product team so it will be resolved in the future release of windows.  The documentation in this regard is  correct and doesn’t need any change.

     

    Thanks

     

    Hongwei Sun-MSFT


    hongwei
    Wednesday, June 25, 2008 10:00 PM

All replies

  • Looking at this further, I've also found that Vista enforced unlock requests coming before lock requests in the array. This isn't mentioned in the docs (in fact, the docs don't give any semantics at all!).

    If you give a unlock after a lock in the same request, you get STATUS_INVALID_PARAMETER

    Cheers, Tridge

    Tuesday, May 27, 2008 7:13 AM
  • Tridge,

     

       Thank you for the extra information.  We also downloaded network trace from your site without any problem.  We will post our response once we finish our investigation.

     

    Tuesday, May 27, 2008 9:42 PM
  • I've run across some more oddities in SMB2 locking today. I now suspect the SMB2 locking code in
    w2008 and vista is just broken. If you look at the SMB2-LOCK test in the latest Samba4 smbtorture
    you'll see some examples of very strange behaviour. gentest_smb2 also quickly spots differences
    between Samba4 and 2008 locking behaviour which looks to me like windows bugs.

    I suspect there are bugs in the code in w2008 and vista which handles the traversal of the lock array
    passed in SMB2 lock requests.

    Cheers, Tridge

    Wednesday, May 28, 2008 11:13 AM
  • Thank you for the information provided.     We are wondering if you can provide us  network traces  for SMB2-Lock   and genetest_smb2 tests  that you mentioned in your post.     It  can really help us to evaluate the issue.   From the network trace  you provided us (smb2_auto_unlock.cap), I noticed  that the Lock length and offset  for each lock and unlock command are all 0xFFFFFFFFFFFFFFFF.    Is this what you try to set in your testing  ?         Thanks again for your patience.

    Thursday, May 29, 2008 12:07 AM
  • Yes, the setting of 0xFFFFFFFFFFFFFFFF was deliberate. The problems shows up at any offset or length though.

    I've put a complete SMB2-LOCK test capture at http://samba.org/~tridge/smb2_lock_vista.cap

    If you look at the locks starting at frame 209 you can see a simple example at offset 0 with length 1. I'm pretty sure this is just a bug in the SMB2 locking code in Vista and w2008. I can't imagine why this would be deliberate.

    Cheers, Tridge



    Thursday, May 29, 2008 9:38 PM
  • Is your VISTA using SP1?  I realize this may seem obvious, and this issue could be much deeper, but because our ISAM-style flat-file database system just hit the VISTA locking issue, we checked with MS and they said SP1 will fix it (specifically mrxsmb2.sys must be version 6.0.6000.20513; our inital testing looks good, but it hasn't been thorough yet).  But your posting leaves me uneasy, wondering if there is yet more to this issue.  Methinks I will try to schedule in some byte-locking tests.

    Thanks in advance,
    Rod
    • Proposed as answer by KeithHa Wednesday, June 25, 2008 7:55 PM
    Wednesday, June 11, 2008 11:14 PM
  •  

    Tridge,

     

      Based on the information you provided, we confirmed that this is a problem in  our  implementation that should be fixed.  We will report this problem to the product team so it will be resolved in the future release of windows.  The documentation in this regard is  correct and doesn’t need any change.

     

    Thanks

     

    Hongwei Sun-MSFT


    hongwei
    Wednesday, June 25, 2008 10:00 PM