MacOS Ventura, compounded flush and close, and io_uring woes

[Jeremy Allison]

On Thu, Sep 22, 2022 at 09:49:52AM -0400, Andrew Walker via samba-technical wrote:
>Hey all,
>
>I've been seeing some issues with the MacOS Ventura beta.
>
>```
>485 15.031755 192.168.0.164 192.168.0.160 SMB2 246 Flush Request File:
>Screen Shot 2022-08-12 at 11.05.32 AM.png;Close Request File: Screen Shot
>2022-08-12 at 11.05.32 AM.png
>```
>Ventura compounds FLUSH and CLOSE requests
>
>```
>486 15.032381 192.168.0.160 192.168.0.164 SMB2 278 Flush Response, Error:
>STATUS_INTERNAL_ERROR;Close Response
>```
>We fail with STATUS_INTERNAL_ERROR on FLUSH request because we hit this:
>```
>        if (req->in.vector_count > req->current_idx +
>SMBD_SMB2_NUM_IOV_PER_REQ) {
>                /*
>                 * We're trying to go async in a compound request
>                 * chain. This is only allowed for opens that cause an
>                 * oplock break or for the last operation in the
>                 * chain, otherwise it is not allowed. See
>                 * [MS-SMB2].pdf note <206> on Section 3.3.5.2.7.
>                 */
>                const uint8_t *inhdr = SMBD_SMB2_IN_HDR_PTR(req);
>
>                if (SVAL(inhdr, SMB2_HDR_OPCODE) != SMB2_OP_CREATE) {
>                        /*
>                         * Cancel the outstanding request.
>                         */
>                        bool ok = tevent_req_cancel(req->subreq);
>                        if (ok) {
>                                return NT_STATUS_OK;
>                        }
>                        TALLOC_FREE(req->subreq);
>                        return smbd_smb2_request_error(req,
>                                NT_STATUS_INTERNAL_ERROR);
>                }
>        }
>```
>
>The TALLOC_FREE() here triggers the
>vfs_io_uring_request_state_deny_destructor which destroys the uring config,
>and closes the ring_fd. Needless to say this is slightly less than
>felicitous.
>
>I have two questions regarding this:
>
>1) Are we sure this is the correct behavior vis-a-vis compounded requests?
>C.F.  MS-SMB2 note:
>https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/a64e55aa-1152-48e4-8206-edd96444e7f7#Appendix_A_245
>```
><245> Section 3.3.5.2.7: In Windows Vista and Windows Server 2008, when an
>operation in a compound request requires asynchronous processing,
>Windows-based servers fail them with STATUS_INTERNAL_ERROR except for the
>following two cases: when a create request in the compound request triggers
>an oplock break, or when the operation is last in the compound request.
>```
>The above appears to be something specific to Windows Vista and Server 2008.

The behavior of going async inside a compound request is less than
well documented. This statement:

https://lists.samba.org/archive/cifs-protocol/2017-July/003064.html

is incorrect, as my early test code run against Windows 2022 shows.

I'm planning on raising a dochelp request to get this clarified.

The MacOS client coders are aware of this issue and I believe
(but cannot speak for them) that they're planning on removing
this behavior before general release.