MacOS Ventura, compounded flush and close, and io_uring woes

[Andrew Walker]

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.

2) Has anyone been working towards adding a more granular cancellation
mechanism for vfs_io_uring?

Andrew