From: Jens Axboe <axboe@kernel.dk>
To: Keith Busch <kbusch@kernel.org>, Keith Busch <kbusch@meta.com>
Cc: linux-block@vger.kernel.org, csander@purestorage.com,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCHv7] blk-integrity: support arbitrary buffer alignment
Date: Sun, 22 Feb 2026 09:29:50 -0700 [thread overview]
Message-ID: <b1c7cb9b-f790-4e3d-b1bd-4f4f516f9b3a@kernel.dk> (raw)
In-Reply-To: <aZYy3L-UVjgNQS11@kbusch-mbp>
On 2/18/26 2:45 PM, Keith Busch wrote:
> On Tue, Nov 25, 2025 at 10:57:18AM -0800, Keith Busch wrote:
>> From: Keith Busch <kbusch@kernel.org>
>>
>> A bio segment may have partial interval block data with the rest
>> continuing into the next segments because direct-io data payloads only
>> need to align in memory to the device's DMA limits.
>>
>> At the same time, the protection information may also be split in
>> multiple segments. The most likely way that may happen is if two
>> requests merge, or if we're directly using the io_uring user metadata.
>> The generate/verify, however, only ever accessed the first bip_vec.
>>
>> Further, it may be possible to unalign the protection fields from the
>> user space buffer, or if there are odd additional opaque bytes in front
>> or in back of the protection information metadata region.
>>
>> Change up the iteration to allow spanning multiple segments. This patch
>> is mostly a re-write of the protection information handling to allow any
>> arbitrary alignments, so it's probably easier to review the end result
>> rather than the diff.
>>
>> Martin reports many SCSI controllers are not able to handle interval
>> data composed of multiple segments when PI is used, so this patch
>> introduces a new integrity limit that a low level driver can set to
>> notify that it is capable of handling that, default to false. The nvme
>> driver is the first one to enable it in this patch. Everyone else will
>> force DMA alignment to the logical block size to ensure interval data is
>> always aligned within a single segment.
>
> Hi Jens,
> It just came to my attention that this one is still outstanding. Any
> thoughts about pulling this in? I may have to rebase it, but just want
> to check before doing that.
Looks like that got missed. If you rebase it, let's take a look and see
if we can do it for this kernel release. It is on the bigger side though
for this deep into the merge window... But since it's still early days
for the release as a whole, we may be able to sneak it in.
--
Jens Axboe
next prev parent reply other threads:[~2026-02-22 16:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-25 18:57 [PATCHv7] blk-integrity: support arbitrary buffer alignment Keith Busch
2026-02-18 21:45 ` Keith Busch
2026-02-22 16:29 ` Jens Axboe [this message]
2026-02-23 16:31 ` Keith Busch
2026-02-24 14:28 ` Jens Axboe
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=b1c7cb9b-f790-4e3d-b1bd-4f4f516f9b3a@kernel.dk \
--to=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=kbusch@meta.com \
--cc=linux-block@vger.kernel.org \
--cc=martin.petersen@oracle.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