Re: [RFC PATCH 2/2] nvme/core: advertise BLK_EXPECTED_REF_TAG_CAPABLE

[Caleb Sander Mateos]

On Tue, Jul 14, 2026 at 6:53 AM Christoph Hellwig <hch@xxxxxx> wrote:
>
> On Sat, Jun 27, 2026 at 12:19:33AM -0600, Caleb Sander Mateos wrote:
> > NVMe Read, Write, and Write Zeroes commands include an (E)ILBRT field to
> > specify the expected initial reference tag for the controller to check
> > against the ref tags in the protection information buffer. However, the
> > NVMe driver currently always sets (E)ILBRT to the lower bits of the LBA.
> > The block integrity layer generates/verifies the PI ref tags according
> > to the bio's ref tag seed, so it must "remap" the ref tags, adjusting
> > for the difference between the ref tag seed and the absolute integrity
> > interval number (= LBA).
> >
> > If a request has an integrity payload, set (E)ILBRT to its ref tag seed
> > so no ref tag remapping is required. Set BLK_EXPECTED_REF_TAG_CAPABLE in
> > NVMe devices' enum blk_integrity_flags to skip the block integrity layer
> > ref tag remapping.
>
> I don't really understand how this is supposed to work.  For type 1 PI,
> NVMe requires (E)ILBRT to match the lower bits of the start LBA:

Good point. I suppose we could only set BLK_EXPECTED_REF_TAG_CAPABLE
for namespaces that report Type 2 PI.

>
>   If the namespace is formatted for Type 1 protection, the value of the
>   computed reference tag for the first logical block of the command is
>   the value contained in the Initial Logical Block Reference Tag (ILBRT)
>   or Expected Initial Logical Block Reference Tag (EILBRT) field in the
>   command, and the computed reference tag is incremented for each
>   subsequent logical block. The controller shall complete the command
>   with a status of Invalid Protection Information if the ILBRT field or
>   the EILBRT field does not match the value of the least significant bits
>   of the SLBA field sized to the number of bits in the Logical Block
>   Reference Tag"
>
> For Type 2 this remapping could work, but doing it unconditionally
> will make all data written using and earlier kernel in a partition
> unreadable once this changes has been applied.

I mentioned this in the cover letter (and that's why I marked these
patches "RFC"). Unless you have a clever idea, it does seem like an
insurmountable obstacle here.

Thanks,
Caleb