[cifs-protocol] 114111212024789 Handling SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context

[Sreekanth Nadendla]

Hello Anubhav,
Upon further analysis today, we have found that the observed behavior is a result of race condition with respect to oplock processing. Below are additional details. This explains the behavior you are seeing.

Some background about CreateGUID.

CreateGuid is used to allow a client to replay an open for which it has not seen the response. The idea is when the client does not know the SMB2 FID, it can’t use the durable v1 form of reconnecting to the Open. Client is expected to issue a replay, but there is no way to refer to a previous open.  In this situation, by allowing the client to provide a GUID that identifies an open, they can refer to it.  So for this purpose after processing a create, the server maintains this value in a cache. This cache is maintained for creates that we are not sure the client has seen the response for.


When the client issues a subsequent request with actual file id, it has now acknowledged that it knows the SMB2 file id (i.e. it received the create response) so a recovery of a handle will now be a resume and NOT a replay.  This means that caching the create by CreateGuid is no longer necessary, and as such, when Server receives a request using the SMB2 file id, it removes it from the cache as it is no longer needed.

oplock break acknowledgement serves as a request using the SMB2 file id.  As such there is a race occurring here between when the initial operation processes and the result that is returned.   In the case where DUPLICATE_OBJECTID is returned, we see the response went out at 54.426658 and the oplock break ack was received at 54.4279230.   (i.e. oplock ack is after failure, and thus the entry was still in the caching table at create complete.)   In the case of success we see oplock break ack arrived at 20.52079 and create response was sent at 20.52274.  So oplock break ACK removed the createGUID value from server’s cache  and hence no STATUS_DUPLICATE_OBJECTID.

Note that both REPLAY in the header and the CreateGUID in the create context are properties of the 3.x dialect
In a normal usecase scenario for 3.x dialect, the client is expected to set SMB2_FLAGS_REPLAY_OPERATION bit with second create Request.



Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications

From: Sreekanth Nadendla
Sent: Wednesday, November 26, 2014 11:22 AM
To: 'Anubhav Rakshit'
Cc: 'cifs-protocol at samba.org'; MSSolve Case Email
Subject: RE: 114111212024789 Handling SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context

Hello Anubhav, can you tell me if this issue is blocking your implementation ? From our attempts to repro, we find that it does not reproduce at will and is timing dependent. Can you state if this reproduces reliably all the time at your end ? Would you be able to share your setup details ?


Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications

From: Sreekanth Nadendla
Sent: Wednesday, November 12, 2014 4:52 PM
To: Anubhav Rakshit
Cc: cifs-protocol at samba.org<mailto:cifs-protocol at samba.org>; MSSolve Case Email
Subject: 114111212024789 Handling SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context

Hello Anubhav,
I am the engineer who will be working with you on this issue. I am currently researching the problem and will provide you with an update soon. Thank you for your patience.


Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications



From: Anubhav Rakshit [mailto:anubhav.rakshit at gmail.com]
Sent: Wednesday, November 12, 2014 12:58 AM
To: Interoperability Documentation Help
Cc: cifs-protocol at samba.org<mailto:cifs-protocol at samba.org>
Subject: Handling SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 Create Context


With reference to MS-SMB2  v20140502 section 3.3.5.9.10 I am trying to test the following scenario as mentioned in the specs:

If an Open is found and the SMB2_FLAGS_REPLAY_OPERATION bit is not set in the SMB2 header,
the server MUST fail the request with STATUS_DUPLICATE_OBJECTID.



I have two test cases. In one of the test cases, I get the expected error STATUS_DUPLICATE_OBJECTID and in the other I get STATUS_SUCCESS.



Case 1:
1.    Send SMB2_CREATE request with SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 context to server. This call succeeds.
2.    Re-send the exact same request as above and the server fails the request with STATUS_DUPLICATE_OBJECTID. Also the server sends an Oplock break notification.

Case 2:
1.    Send SMB2_CREATE request with SMB2_CREATE_DURABLE_HANDLE_REQUEST_V2 context to server. This call succeeds.
2.    Send SMB2_QUERY_INFO on the above File Handle. This call succeeds.
3.    Re-send the exact same request as 1. We see an Oplock break notification triggered. Also the SMB2_CREATE succeeds.

According to the specs SMB2_CREATE in 3. should have failed with STATUS_DUPLICATE_OBJECTID. Can you please explain why the server behaves differently in this case?



I am also attaching the Message Analyzer captures for both the cases. For Case 1. look at "duplicate_objectid_pass" Frame 3444. For Case 2. look at "duplicate_objectid_fail" Frame 45.



Thanks,

anubhav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20141127/87531276/attachment-0001.html>