All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: huang-jl <huang-jl@deepseek.com>
Cc: csander@purestorage.com, axboe@kernel.dk,
	io-uring@vger.kernel.org, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] io_uring: fix nr_segs calculation in io_import_kbuf
Date: Wed, 17 Dec 2025 17:25:23 +0800	[thread overview]
Message-ID: <aUJ3A7Ec7EVAI3FB@fedora> (raw)
In-Reply-To: <20251217062632.113983-1-huang-jl@deepseek.com>

On Wed, Dec 17, 2025 at 02:26:32PM +0800, huang-jl wrote:
> io_import_kbuf() calculates nr_segs incorrectly when iov_offset is
> non-zero after iov_iter_advance(). It doesn't account for the partial
> consumption of the first bvec.
> 
> The problem comes when meet the following conditions:
> 1. Use UBLK_F_AUTO_BUF_REG feature of ublk.
> 2. The kernel will help to register the buffer, into the io uring.
> 3. Later, the ublk server try to send IO request using the registered
>    buffer in the io uring, to read/write to fuse-based filesystem, with
> O_DIRECT.
> 
> From a userspace perspective, the ublk server thread is blocked in the
> kernel, and will see "soft lockup" in the kernel dmesg.
> 
> When ublk registers a buffer with mixed-size bvecs like [4K]*6 + [12K]
> and a request partially consumes a bvec, the next request's nr_segs
> calculation uses bvec->bv_len instead of (bv_len - iov_offset).
> 
> This causes fuse_get_user_pages() to loop forever because nr_segs
> indicates fewer pages than actually needed.
> 
> Specifically, the infinite loop happens at:
> fuse_get_user_pages()
>   -> iov_iter_extract_pages()
>     -> iov_iter_extract_bvec_pages()
> Since the nr_segs is miscalculated, the iov_iter_extract_bvec_pages
> returns when finding that i->nr_segs is zero. Then
> iov_iter_extract_pages returns zero. However, fuse_get_user_pages does
> still not get enough data/pages, causing infinite loop.
> 
> Example:
>   - Bvecs: [4K, 4K, 4K, 4K, 4K, 4K, 12K, ...]
>   - Request 1: 32K at offset 0, uses 6*4K + 8K of the 12K bvec
>   - Request 2: 32K at offset 32K
>     - iov_offset = 8K (8K already consumed from 12K bvec)
>     - Bug: calculates using 12K, not (12K - 8K) = 4K
>     - Result: nr_segs too small, infinite loop in fuse_get_user_pages.
> 
> Fix by accounting for iov_offset when calculating the first segment's
> available length.
> 
> Fixes: b419bed4f0a6 ("io_uring/rsrc: ensure segments counts are correct on kbuf buffers")
> Signed-off-by: huang-jl <huang-jl@deepseek.com>
> ---
>  v2: Optimize the logic to handle the iov_offset and add Fixes tag.
> 
>  > Please add a Fixes tag
>  
>  Thanks for your notice, this is my first time to send patch to linux. I
>  have add the Fixes tag, but not sure if I am doing it correctly.
> 
>  > Would a simpler fix be just to add a len += iter->iov_offset before the loop?
>  
>  Great suggestion! I have tried it, and also fix the bug correctly.
> 
>  io_uring/rsrc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/io_uring/rsrc.c b/io_uring/rsrc.c
> index a63474b331bf..41c89f5c616d 100644
> --- a/io_uring/rsrc.c
> +++ b/io_uring/rsrc.c
> @@ -1059,6 +1059,7 @@ static int io_import_kbuf(int ddir, struct iov_iter *iter,
>  	if (count < imu->len) {
>  		const struct bio_vec *bvec = iter->bvec;
>  
> +		len += iter->iov_offset;
>  		while (len > bvec->bv_len) {
>  			len -= bvec->bv_len;
>  			bvec++;

Reviewed-by: Ming Lei <ming.lei@redhat.com>



Thanks,
Ming


  reply	other threads:[~2025-12-17  9:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-17  3:26 [PATCH 01/01] io_uring: fix nr_segs calculation in io_import_kbuf huang-jl
2025-12-17  5:33 ` Caleb Sander Mateos
2025-12-17  6:26   ` [PATCH v2] " huang-jl
2025-12-17  9:25     ` Ming Lei [this message]
2025-12-17 14:36     ` Jens Axboe
2025-12-17 18:08     ` Caleb Sander Mateos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aUJ3A7Ec7EVAI3FB@fedora \
    --to=ming.lei@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=csander@purestorage.com \
    --cc=huang-jl@deepseek.com \
    --cc=io-uring@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.