On 3/27/23 8:55 PM, Pengfei Xu wrote:
> Hi Jens Axboe,
>
> On 2023-03-27 at 20:08:25 -0600, Jens Axboe wrote:
>> Unless we have at least one entry queued, then don't call into
>> io_poll_remove_entries(). Normally this isn't possible, but if we
>> retry poll then we can have ->nr_entries cleared again as we're
>> setting it up. If this happens for a poll retry, then we'll still have
>> at least REQ_F_SINGLE_POLL set. io_poll_remove_entries() then thinks
>> it has entries to remove.
>>
>> Clear REQ_F_SINGLE_POLL and REQ_F_DOUBLE_POLL unconditionally when
>> arming a poll request.
>>
>> Fixes: c16bda37594f ("io_uring/poll: allow some retries for poll triggering spuriously")
>> Cc: stable@xxxxxxxxxxxxxxx
>> Reported-by: Pengfei Xu <pengfei.xu@xxxxxxxxx>
>> Signed-off-by: Jens Axboe <axboe@xxxxxxxxx>
>>
>> ---
>>
>> diff --git a/io_uring/poll.c b/io_uring/poll.c
>> index 795facbd0e9f..55306e801081 100644
>> --- a/io_uring/poll.c
>> +++ b/io_uring/poll.c
>> @@ -726,6 +726,7 @@ int io_arm_poll_handler(struct io_kiocb *req, unsigned issue_flags)
>> apoll = io_req_alloc_apoll(req, issue_flags);
>> if (!apoll)
>> return IO_APOLL_ABORTED;
>> + req->flags &= ~(REQ_F_SINGLE_POLL | REQ_F_DOUBLE_POLL);
>> req->flags |= REQ_F_POLLED;
>> ipt.pt._qproc = io_async_queue_proc;
>>
> Thanks for your patch!
> I have tested the above patch on top of v6.3-rc4 kernel.
> This issue was fixed.
> Reproduced code from syzkaller: https://github.com/xupengfe/syzkaller_logs/blob/main/230327_041425_io_poll_remove_entries/repro.c
> One more info, bisect methodology comes from myself, not from syzkaller.
Great, thanks for testing!
--
Jens Axboe
