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

On 7/26/26 6:13 PM, Gabriel Krisman Bertazi wrote:
> Gabriel Krisman Bertazi <[email protected]> writes:
> 
>> 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.
> 
> Hello, do you disagree or did I miss anything?

Still on vacation and sporadically available, just haven't had time to
look at it yet. I agree it looks fishy! I would encourage you to dig into
the kernel side and get to the bottom of it.

-- 
Jens Axboe