[cifs-protocol] [MS-SMB2] Question wrt to copy-chunk ioctl

[Ralph Böhme]

Hello dochelp,

while working on a change of the Samba SMB2 server-side copy-chunk
implementation I noticed the following.

Previously in Samba the copy-chunk implementation was synchronous wrt to the
individual SRV_COPYCHUNK chunks in the SRV_COPYCHUNK_COPY packet. As a result
the chunk were copied sequentially maintaining the order from the
SRV_COPYCHUNK_COPY packet.

The new implementation will be asynchronous using a threadpool with worker
threads to do the IO, scheduling all SRV_COPYCHUNKs of a SRV_COPYCHUNK_COPY
packet in parallel, so no ordering guarantees are maintained.

The Samba testsuite contains a copy-chunk test that now fails with the async
implementation. The test deliberately crafts a SRV_COPYCHUNK_COPY request that
requires ordering:

        /* first chunk overwrites existing dest data */
        cc_copy.chunks[0].source_off = 0;
        cc_copy.chunks[0].target_off = 0;
        cc_copy.chunks[0].length = 4096;

        /* second chunk overwrites the first */
        cc_copy.chunks[1].source_off = 4096;
        cc_copy.chunks[1].target_off = 0;
        cc_copy.chunks[1].length = 4096;

The test verifies the destination file content after the copy-chunk request
which will fail if the server doesn't schedule the above chunks in order. So
occasionally, depending on timing and thread scheduling in the kernel, this test
failed.

I was then running this particular test against a Windows 2016 server hoping it
might occasionally fail as well which would have prooved that the server
implemeted this asynchronously as well.

Unfortunately after running the test in a loop for quite some time, it never
failed, so I can't infer the server implementation.

The async out-of-order copy-chunk behaviour seems to be allowed by MS-SMB2
3.3.5.15.6 "Handling a Server-Side Data Copy Request" which notices:

   ... . If no such locks are found, starting with the first chunk received in
   the Chunks field, the server MUST copy each chunk from the source file to the
   destination file in an implementation-specific manner. ...

So my question is:

what is the expectation here from a protocol perspective and will a real world
Windows client ever issue such requests that require ordering ?

Thanks for you help!

Cheerio!
-slow