[cifs-protocol] [EXTERNAL] Seeking clarification of SMB3 async behavior in a compound request. - TrackingID#2209220040008649

[Kristian Smith]

[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.