Re: [PATCH v2] io_uring: commit non-pollable provided mapped buffers upfront

[Hao Xu <hao.xu@linux.dev>]

On 6/16/22 20:34, Jens Axboe wrote:
> For recv/recvmsg, IO either completes immediately or gets queued for a
> retry. This isn't the case for read/readv, if eg a normal file or a block
> device is used. Here, an operation can get queued with the block layer.
> If this happens, ring mapped buffers must get committed immediately to
> avoid that the next read can consume the same buffer.
> 
> Check if we're dealing with pollable file, when getting a new ring mapped
> provided buffer. If it's not, commit it immediately rather than wait post
> issue. If we don't wait, we can race with completions coming in, or just
> plain buffer reuse by committing after a retry where others could have
> grabbed the same buffer.
> 
> Fixes: c7fb19428d67 ("io_uring: add support for ring mapped supplied buffers")
> Signed-off-by: Jens Axboe <axboe@kernel.dk>
> 
> ---
> 
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 5d479428d8e5..b6e75f69c6b1 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -3836,7 +3836,7 @@ static void __user *io_ring_buffer_select(struct io_kiocb *req, size_t *len,
>   	req->buf_list = bl;
>   	req->buf_index = buf->bid;
>   
> -	if (issue_flags & IO_URING_F_UNLOCKED) {
> +	if (issue_flags & IO_URING_F_UNLOCKED || !file_can_poll(req->file)) {
>   		/*
>   		 * If we came in unlocked, we have no choice but to consume the
>   		 * buffer here. This does mean it'll be pinned until the IO
> 

Looks good,
Reviewed-by: Hao Xu <howeyxu@tencent.com>