[cifs-protocol] [EXTERNAL] Seeking clarification of SMB3 async behavior in a compound request. - TrackingID#2209220040008649
Jeff McCashland (He/him)
jeffm at microsoft.com
Fri Sep 23 02:19:26 UTC 2022
[Kristian to BCC]
Hi Jeremy,
I will be assisting you with this issue. Tomorrow I will send instructions for collecting and uploading traces.
Best regards,
Jeff McCashland (He/him) | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)
Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300
-----Original Message-----
From: Kristian Smith <Kristian.Smith at microsoft.com>
Sent: Thursday, September 22, 2022 4:31 PM
To: Jeremy Allison <jra at samba.org>
Cc: cifs-protocol at lists.samba.org; metze <metze at samba.org>; Microsoft Support <supportmail at microsoft.com>
Subject: RE: [EXTERNAL] Seeking clarification of SMB3 async behavior in a compound request. - TrackingID#2209220040008649
[DocHelp to Bcc]
Hi Jeremy,
Thank you for your request. The case number 2209220040008649 has been created for this inquiry. One of our team members will follow-up with you soon.
Regards,
Kristian
Kristian Smith
Support Escalation Engineer
Windows Open Spec Protocols
Office: (425) 421-4442
kristian.smith at microsoft.com
-----Original Message-----
From: Jeremy Allison <jra at samba.org>
Sent: Thursday, September 22, 2022 4:02 PM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: jra at samba.org; cifs-protocol at lists.samba.org; metze <metze at samba.org>
Subject: [EXTERNAL] Seeking clarification of SMB3 async behavior in a compound request.
Hi Dochelp,
I'm seeking clarify on the behavior of compound requests going async in SMB3.
MS-SMB2 states in:
-------------------------------------------------------
3.3.5.2.7.2 Handling Compounded Related Requests
When an operation requires asynchronous processing, all the subsequent operations MUST also be processed asynchronously. The server MUST send an interim response for all such operations as specified in section 3.3.4.2.
-------------------------------------------------------
But this doesn't appear to be the case against Windows 2022.
I have a set of tests that do the following to force asynchronous operation in compound requests against Windows 2022 (thanks to Metze for the ideas for these).
Test #1
Opendir foo <- returns foo-handle
notify on foo-handle
create foo/bar
notify recv
delete foo/bar
Compound --------------
notify on foo-handle
close (compound handle)
--------------
When the server sees the compound request starting with the notify in this test it should have a pending FILE_DELETED notify return queued up and ready to return for the compound notify, so this test should not need to go async at all.
However, Windows 2022 returns NT_STATUS_INTERNAL_ERROR for the compound notify request.
Test #2
Opendir foo <- returns foo-handle
notify on foo-handle
create foo/bar
notify recv
delete foo/bar
Compound --------------
getinfo foo-handle
notify (compound handle)
close (compound handle)
--------------
This test is the same as test #1, with
the addition of the getinfo foo-handle
in the compound to determine how Windows behaves when a request that might go async is in the middle of the compound stream.
When the server sees the compound request starting with the notify in this test it should have a pending DELETE-FILE notify return queued up and ready to return for the compound notify, so this test should not need to go async at all.
However, Windows 2022 returns NT_STATUS_INTERNAL_ERROR for the compound notify request.
Test #3
Opendir foo <- returns foo-handle
notify on foo-handle
create foo/bar
notify recv
Compound --------------
notify foo-handle
close (compound handle)
--------------
When the server sees the compound request starting with the notify in this test it should have no pending requests to return, and so the compound notify should be forced to go async.
However, Windows 2022 returns NT_STATUS_INTERNAL_ERROR for the compound notify request.
Test #4
Opendir foo <- returns foo-handle
notify on foo-handle
notify foo
create foo/bar
notify recv
Compound --------------
getinfo foo-handle
notify (compound handle)
close (compound handle)
--------------
This test is the same as test #1, with
the addition of the getinfo foo-handle
in the compound to determine how Windows behaves when a request that might go async is in the middle of the compound stream.
When the server sees the compound notify request in this test it should have no pending requests to return, and so the compound notify should be forced to go async.
However, Windows 2022 returns NT_STATUS_INTERNAL_ERROR for the compound notify request.
It appears Windows 2022 might treat SMB2_OP_NOTIFY differently to other requests in a compound but I can't find this documented anywhere.
I can send test patches against Samba smbtorture to show reproduction of this locally, or can send in packet traces for any or all of these tests.
Thanks !
Jeremy.
More information about the cifs-protocol
mailing list