public inbox for io-uring@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox