Re: [PATCH] io_uring/poll: fix multishot recv missing EOF on wakeup race

[Pavel Begunkov <asml.silence@gmail.com>]

On 3/16/26 14:28, Jens Axboe wrote:
> On 3/16/26 8:17 AM, Pavel Begunkov wrote:
>> On 3/15/26 16:19, Jens Axboe wrote:
>>> When a socket send and shutdown() happen back-to-back, both fire
>>> wake-ups before the receiver's task_work has a chance to run. The first
>>> wake gets poll ownership (poll_refs=1), and the second bumps it to 2.
>>> When io_poll_check_events() runs, it calls io_poll_issue() which does a
>>> recv that reads the data and returns IOU_RETRY. The loop then drains all
>>> accumulated refs (atomic_sub_return(2) -> 0) and exits, even though only
>>> the first event was consumed. Since the shutdown is a persistent state
>>> change, no further wakeups will happen, and the multishot recv can hang
>>> forever.
>>>
>>> Fix this by only draining a single poll ref after io_poll_issue()
>>> returns IOU_RETRY for the APOLL_MULTISHOT path. If additional wakes
>>> raced in (poll_refs was > 1), the loop iterates again, vfs_poll()
>>> discovers the remaining state.
>>
>> How often will iterate with no effect for normal execution (i.e.
>> no shutdown)? And how costly it'll be? Why not handle HUP instead?
> 
> That is my worry too. I spent a bit of time on it this morning to figure
> out why this is a new issue, and traced it down to 6.16..6.17, and this
> commit in particular:
> 
> commit df30285b3670bf52e1e5512e4d4482bec5e93c16
> Author: Kuniyuki Iwashima <kuniyu@google.com>
> Date:   Wed Jul 2 22:35:18 2025 +0000
> 
>      af_unix: Introduce SO_INQ.
> 
> which is then not the first time I've had to fix fallout from that
> commit. Need to dig a bit deeper. That said, I do also worry a bit about
> missing events. Yes if both poll triggers are of the same type, eg
> POLLIN, then we don't need to iterate again. IN + HUP is problematic, as
> would anything else where you'd need separate handling for the trigger.

Thinking more, I don't think the patch is correct either. Seems you
expect the last recv to return 0, but let's say you have 2 refs and
8K in the rx queue. The first recv call gets 4K b/c some allocation
fails. The 2nd recv call returns another 4K, and now you're in the
same situation as before.

You're trying to rely on a too specific behaviour. HUP handling should
be better. Ideally, the opcode would handle it, e.g. zcrx doesn't have
the problem IIUC, but that might be harder to do.

-- 
Pavel Begunkov