Christoph,
Sorry about the delay. Just got back from vacation.
> I think we'll need to change the in-kernel interface matches the user
> one, and the submitter of the PI data chooses which of the tags to
> generate and check.
Yep. I discussed this with Kanchan a while back.
I don't like having the BIP_USER_CHECK_FOO flags exposed in the block
layer. The io_uring interface obviously needs to expose some flags in
the user API. But there should not be a separate set of BIP_USER_* flags
bolted onto the side of the existing kernel integrity flags.
The bip flags should describe the contents of the integrity buffer and
how the hardware needs to interpret and check that information.
> Martin also mentioned he wanted to see the BIP_CTRL_NOCHECK,
> BIP_DISK_NOCHECK and BIP_IP_CHECKSUM checksum flags exposed. Can you
> explain how you want them to fit into the API? Especially as AFAIK
> they can't work generically, e.g. NVMe never has an IP checksum and
> SCSI controllers might not offer them either. NVMe doesn't have a way
> to distinguish between disk and controller.
I am not sure how to handle the protocol differences other than
returning an error if flags are passed that are not valid for the given
device.
The other alternative is to only expose a generic CHECK or NOCHECK flag
(depending which polarity we prefer) which will enable or disable
checking for both controller and disk in the SCSI case. But that also
means porting the DI test tooling will be impossible.
Another wrinkle is that SCSI does not have a way to directly specify
which tags to check. You can check guard only, check app+ref only, or
all three. But you can't just check the ref tag if that's what you want
to do.
I addressed that in DIX by having individual tag check flags and NVMe
inherited those in PRCHK. But for the SCSI disk itself we're limited to
what RDPROTECT/WRPROTECT can express. And that's why BIP_DISK_NOCHECK
disables checking of all tags and why there are currently no separate
BIP_DISK_NO_{GUARD,APP,REF}_CHECK flags.
> Last but not least the fact that all reads and writes on PI enabled
> devices by default check the guard (and reference if available for the
> PI type) tags leads to a lot of annoying warnings when the kernel or
> userspace does speculative reads.
> Most of this is to read signatures of file systems or partitions, and
> that previously always succeeded, but now returns an error and warns
> in the block layer. I've been wondering a few things here:
Is that on NVMe? It's been a while since I've tried. We don't get errors
for readahead on SCSI, that would be a bug.
--
Martin K. Petersen Oracle Linux Engineering
