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

Jeremy Allison jra at samba.org
Thu Sep 22 23:02:08 UTC 2022


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