Re: [PATCH v2] block: only read from sqe on initial invocation of blkdev_uring_cmd()

[Jens Axboe <axboe@kernel.dk>]

On 5/6/26 10:07 AM, Caleb Sander Mateos wrote:
> On Wed, May 6, 2026 at 3:43 AM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> On 5/5/26 9:32 AM, Caleb Sander Mateos wrote:
>>> On Tue, May 5, 2026 at 12:38?AM Jens Axboe <axboe@kernel.dk> wrote:
>>>>
>>>> This passthrough helper currently only supports discards. Part of that
>>>> command is the start and length, which is read from the SQE. It does
>>>> so on every invocation, where it really should just make it stable
>>>> on the first invocation. This avoids needing to copy the SQE upfront,
>>>> as we only really need those two 8b values stored in our per-req
>>>> payload.
>>>
>>> Maybe I'm missing something, but how does this avoid the SQE copy?
>>> Won't io_uring_cmd_sqe_copy() still copy the SQE if the command issue
>>> is delayed by links/drain/forced async or if the initial issue returns
>>> EAGAIN? The code change looks fine to me, but I'm not sure I
>>> understand the motivation.
>>
>> Because the alternative would be to copy it upfront and then using ->sqe
>> would always be fine. But we can just ensure start/len are stable. The
>> patch is about the latter, not adding any further copy avoidance. Yes if
>> you use async or it's a link or drained, prep will always copy it.
>> That's fine.
> 
> I see what you mean now, makes sense. As for making start/len stable
> in the first place, is this just hardening? Currently, it doesn't look
> like calling blkdev_cmd_discard() again with different start/len
> values after it returned EAGAIN would cause any issues.

Yeah it doesn't cause any issues, just prudent.

-- 
Jens Axboe