Re: [PATCH 1/4] io_uring: add IO_URING_F_INLINE issue flag

[Jens Axboe <axboe@kernel.dk>]

On 6/6/25 11:31 AM, Caleb Sander Mateos wrote:
> On Thu, Jun 5, 2025 at 12:47?PM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> Set when the execution of the request is done inline from the system
>> call itself. Any deferred issue will never have this flag set.
>>
>> Signed-off-by: Jens Axboe <axboe@kernel.dk>
>> ---
>>  include/linux/io_uring_types.h | 2 ++
>>  io_uring/io_uring.c            | 3 ++-
>>  2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/io_uring_types.h b/include/linux/io_uring_types.h
>> index 2922635986f5..054c43c02c96 100644
>> --- a/include/linux/io_uring_types.h
>> +++ b/include/linux/io_uring_types.h
>> @@ -26,6 +26,8 @@ enum io_uring_cmd_flags {
>>         IO_URING_F_MULTISHOT            = 4,
>>         /* executed by io-wq */
>>         IO_URING_F_IOWQ                 = 8,
>> +       /* executed inline from syscall */
>> +       IO_URING_F_INLINE               = 16,
>>         /* int's last bit, sign checks are usually faster than a bit test */
>>         IO_URING_F_NONBLOCK             = INT_MIN,
>>
>> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
>> index cf759c172083..079a95e1bd82 100644
>> --- a/io_uring/io_uring.c
>> +++ b/io_uring/io_uring.c
>> @@ -1962,7 +1962,8 @@ static inline void io_queue_sqe(struct io_kiocb *req)
>>  {
>>         int ret;
>>
>> -       ret = io_issue_sqe(req, IO_URING_F_NONBLOCK|IO_URING_F_COMPLETE_DEFER);
>> +       ret = io_issue_sqe(req, IO_URING_F_NONBLOCK|IO_URING_F_COMPLETE_DEFER|
>> +                               IO_URING_F_INLINE);
> 
> Isn't io_queue_sqe() also called from io_req_task_submit(), which is
> an io_req_tw_func_t callback? Task work runs after the SQ slots have
> already been returned to userspace, right? Before the unconditional
> memcpy() was added, we had observed requests in linked chains with
> corrupted SQEs due to the async task work issue.

It's really just a patch ordering issue, as per the other email.

> As is, it looks like IO_URING_F_INLINE is just the inverse of
> IO_URING_F_IOWQ, so it may not be necessary to add a new flag. But I
> can see how core io_uring might add additional async issue cases in
> the future.

I'd greatly prefer a separate flag, it's more robust than tying it
to some other flag.

-- 
Jens Axboe