From: Naman Jain <namjain@linux.microsoft.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@lst.de>,
Chaitanya Kulkarni <kch@nvidia.com>,
John Hubbard <jhubbard@nvidia.com>,
Logan Gunthorpe <logang@deltatee.com>,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
Saurabh Sengar <ssengar@linux.microsoft.com>,
Long Li <longli@microsoft.com>,
Michael Kelley <mhklinux@outlook.com>,
namjain@linux.microsoft.com
Subject: [PATCH 0/2] block: fix pgmap handling for zone device pages in bio merge paths
Date: Wed, 1 Apr 2026 08:23:27 +0000 [thread overview]
Message-ID: <20260401082329.1602328-1-namjain@linux.microsoft.com> (raw)
When zone device memory is registered in multiple chunks, each chunk
gets its own dev_pagemap. A single bio can contain bvecs from different
pgmaps -- iov_iter_extract_bvecs() breaks at pgmap boundaries but the
outer loop in bio_iov_iter_get_pages() continues filling the same bio.
There are two problems with the current code:
1. biovec_phys_mergeable() has no pgmap check, so the request merge,
DMA mapping, and integrity merge paths can coalesce physically
contiguous bvec segments from different pgmaps. This makes it
impossible to recover the correct pgmap for the merged segment
via page_pgmap().
2. bio_add_page() and bio_integrity_add_page() reject pages from a
different pgmap entirely (returning 0), rather than just skipping
the merge and adding them as new bvec entries. This forces callers
to start a new bio unnecessarily.
Patch 1 fixes the merge-path gap by adding a pgmap check to
biovec_phys_mergeable().
Patch 2 fixes the bio_add_page() and bio_integrity_add_page() API
behavior, moving the pgmap check into the merge conditional so
different-pgmap pages can be added as separate bvec entries. This
depends on patch 1 being in place.
Naman Jain (2):
block: add pgmap check to biovec_phys_mergeable
block: allow different-pgmap pages as separate bvecs in bio_add_page
block/bio-integrity.c | 6 ++----
block/bio.c | 6 ++----
block/blk.h | 2 ++
3 files changed, 6 insertions(+), 8 deletions(-)
--
2.43.0
next reply other threads:[~2026-04-01 8:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-01 8:23 Naman Jain [this message]
2026-04-01 8:23 ` [PATCH 1/2] block: add pgmap check to biovec_phys_mergeable Naman Jain
2026-04-01 14:07 ` Christoph Hellwig
2026-04-01 8:23 ` [PATCH 2/2] block: allow different-pgmap pages as separate bvecs in bio_add_page Naman Jain
2026-04-01 14:08 ` Christoph Hellwig
2026-04-02 5:21 ` Naman Jain
2026-04-02 5:30 ` Christoph Hellwig
2026-04-02 8:55 ` Naman Jain
2026-04-07 5:52 ` Christoph Hellwig
2026-04-07 7:08 ` Naman Jain
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=20260401082329.1602328-1-namjain@linux.microsoft.com \
--to=namjain@linux.microsoft.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=jhubbard@nvidia.com \
--cc=kch@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=longli@microsoft.com \
--cc=mhklinux@outlook.com \
--cc=ssengar@linux.microsoft.com \
/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