From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Caleb Sander Mateos <csander@purestorage.com>
Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
Chaitanya Kulkarni <kch@nvidia.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Anuj Gupta <anuj20.g@samsung.com>,
linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-scsi@vger.kernel.org, target-devel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/6] block: fix integrity offset/length conversions
Date: Thu, 16 Apr 2026 23:26:11 -0400 [thread overview]
Message-ID: <yq18qams3re.fsf@ca-mkp.ca.oracle.com> (raw)
In-Reply-To: <20260417015732.2692434-1-csander@purestorage.com> (Caleb Sander Mateos's message of "Thu, 16 Apr 2026 19:57:26 -0600")
Hi Caleb!
> The block layer's integrity code currently sets the seed (initial
> reference tag) in units of 512-byte sectors but increments it in units
> of integrity intervals
I don't necessarily agree with the premise that the seed needs to be
expressed in any particular unit. The seed is a start value, nothing
more.
We happen to set it to the block number in the block layer since we need
to be able to know what to compare against on completion (for Type 1 +
the restrictive Linux implementation of Type 2). But that does not imply
that the seed needs to be specified in any particular unit. Submitters
set the seed to whichever value makes sense to them (i.e. it could be
the offset within a file as opposed to the eventual LBA on the backend
device). And then that seed is incremented by 1 for each integrity
interval of data in the PI sent to/received from the device. The
conversion between the submitter's view of what the first ref tag should
be (i.e. seed) and what is required by the hardware (for instance lower
32 bits of device LBA) is the reason we perform remapping. The seed is
intentionally different in the submitter's protection envelope compared
to the device's protection envelope.
Using the block layer block number as seed was just a convenience since
that provided a predictable value for any I/O that had its PI
autogenerated. I never intended for the actual LBA to be used as seed
value on a 4Kn device. Initially we just used 0 as the seed. Leveraging
the block number just added a bit of additional protection.
I confess I haven't tested 4Kn in a while since things sort of converged
on 512e. But I used to run nightly tests on a SCSI storage with 4Kn
blocks just fine.
> This looks to be a longstanding bug affecting block devices that
> support integrity with block sizes > 512 bytes; I'm surprised it
> wasn't noticed before.
Are you seeing this with NVMe or SCSI?
--
Martin K. Petersen
next prev parent reply other threads:[~2026-04-17 3:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 1:57 [PATCH v3 0/6] block: fix integrity offset/length conversions Caleb Sander Mateos
2026-04-17 1:57 ` [PATCH v3 1/6] block: use integrity interval instead of sector as seed Caleb Sander Mateos
2026-04-17 1:57 ` [PATCH v3 2/6] bio-integrity-fs: pass data iter to bio_integrity_verify() Caleb Sander Mateos
2026-04-17 1:57 ` [PATCH v3 3/6] blk-integrity: take u64 in bio_integrity_intervals() Caleb Sander Mateos
2026-04-17 1:57 ` [PATCH v3 4/6] bio-integrity-fs: use integrity interval instead of sector as seed Caleb Sander Mateos
2026-04-17 1:57 ` [PATCH v3 5/6] t10-pi: use bio_integrity_intervals() helper Caleb Sander Mateos
2026-04-17 1:57 ` [PATCH v3 6/6] blk-integrity: avoid sector_t in bip_{get,set}_seed() Caleb Sander Mateos
2026-04-17 3:26 ` Martin K. Petersen [this message]
2026-04-17 15:10 ` [PATCH v3 0/6] block: fix integrity offset/length conversions 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=yq18qams3re.fsf@ca-mkp.ca.oracle.com \
--to=martin.petersen@oracle.com \
--cc=anuj20.g@samsung.com \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=hch@lst.de \
--cc=kch@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=sagi@grimberg.me \
--cc=target-devel@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