MacOS Ventura, compounded flush and close, and io_uring woes

Andrew Walker awalker at
Thu Sep 22 13:49:52 UTC 2022

Hey all,

I've been seeing some issues with the MacOS Ventura beta.

485 15.031755 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 SMB2 278 Flush Response, Error:
We fail with STATUS_INTERNAL_ERROR on FLUSH request because we hit this:
        if (req->in.vector_count > req->current_idx +
                 * 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
                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;
                        return smbd_smb2_request_error(req,

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

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:
<245> Section 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?


More information about the samba-technical mailing list