Re: [PATCH liburing 1/2] test/send_recvmsg: Preserve msghdr until op_recvmsg completes

Gabriel Krisman Bertazi <[email protected]> writes:

> Jens Axboe <[email protected]> writes:
>
>> On 7/22/26 12:17 PM, Gabriel Krisman Bertazi wrote:
>>> msghdr is allocated on the stack at recv_prep, which means it may go out
>>> of scope before the kernel has a chance to complete the operation.  This
>>> results in spurious test failures when we reach far enough into recv_fn
>>> to reuse the stack space before op_recvmsg executes.  I found it easily
>>> reproducible when compiling with '-O0 -g3' to avoid gcc from optimizing
>>> further local variables out of the stack.
>>
>> Hmm, but that should be fine as long as a) we submit in scope, and b)
>> we're not using SQPOLL, where it does need to remain consistent until
>> completion.
>>
>> And recv_prep() certainly submits before it returns, and we're not using
>> SQPOLL. So I'm curious what issue this is?? Same questions on patch 2.
>
> Hm, I assumed it was submitted via iowq, which would explain this,
> because the execution in io_recvmsg() passes a pointer to the original
> memory:

So, __sys_recvmsg_sock during the inline attempt throws -EAGAIN at
first, which makes io_recv return IOU_RETRY, which punts to tw after
the socket is ready.  By tracing, I can see the tw is executed only
during the io_uring_enter from io_uring_wait_cqe, which is when
__sys_recvmsg_sock touches sr->umsg pointing to an already out-of-scope
stack variable.

FWIW, I could only trace this with good old printk.  Any
tracepoint/bpftrace made the issue disappear. I think that is because
with these tracing tools, we end up executing the tw inside the previous
io_uring_enter, since it took time to complete and the socket got ready in
the meantime.

>
>> -- 
>> Jens Axboe
>
> -- 
> Gabriel Krisman Bertazi

-- 
Gabriel Krisman Bertazi