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@vger.kernel.org
> Reported-by: Pengfei Xu <pengfei.xu@intel.com>
> Signed-off-by: Jens Axboe <axboe@kernel.dk>
> 
> ---
> 
> 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.

  Thanks!
  BR.
  -Pengfei(Intel)

> -- 
> Jens Axboe
>