Re: [RFC PATCH v3 5/6] io_uring/cmd: allow reusing SQE storage for completion data

[Yingjie Wang]

On Mon, 9 Nov 2026, Yang Xiuwei wrote:
> io_async_cmd is io_uring's own async state. sqes[] is what
> io_uring_cmd_sqe_copy() points ioucmd->sqe at. Giving that buffer to
> scsi_bsg couples the driver to the io_uring layout and lifetime.

Hi Yang,

Thanks for the review. scsi_bsg passes the required size to the helper
and gets a pointer to the storage back; it does not access io_async_cmd
or sqes[] directly. However, I agree that the helper constrains how
io_uring can reuse that internal storage.

The proposed contract is that, after a successful call, the requested
storage remains valid until io_uring_cmd_done*(). BSG requests 96 bytes;
the current implementation can provide up to 128 bytes. The caller
must also stop using the SQE and must not reissue the command, and
multishot commands cannot use the helper.

Jens, Pavel, would such a completion-storage contract be acceptable
for uring_cmd, or would you prefer the storage to be driver-owned?

> Preallocating the buffer in bsg itself may be a better fit.

Which object did you have in mind for the buffer? With 6/6, end-I/O
frees the request, and the tag can be reused before task work copies
the sense data. Storage that is reused along with the request or tag
would therefore have the same lifetime problem as scmd->sense_buffer.

Queue depth alone also does not bound the number of completed
commands waiting for task work once their tags have been released.
A BSG-owned pool would need a sizing and exhaustion policy.
bsg_open() currently allocates no per-file state.

If driver-owned storage is preferred, I can investigate a per-file
pool for v4. I would need to check that waiting for a free buffer
cannot prevent the task work that returns buffers from running.

Thanks,
Yingjie