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

[Jens Axboe <axboe@kernel.dk>]

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.

-- 
Jens Axboe