fine-grained PI control

[Christoph Hellwig]

Hi all,

I'm trying to kick of a discussion on fine grained control of T10 PI
flags.  This concerns the new io_uring metadata interface including
comments made by Martin in response to earlier series, and observations
on how block devices with PI enabled don't work quite right right now
for a few uses cases.

The SCSI and NVMe PI interfaces allow fine-grained checking of the guard,
reference and app tags.  The io_uring interface exposes them to
userspace, which is useful.  The in-kernel implementation in the posted
patch set only uses these flags when detecting user passthrough and
currently only in the nvme driver.  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.

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.

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 there much of a point in having block layer and driver warnings
   (for NVMe we'll currently get both) by default, or should we leave
   that to the submitter that needs to check errors anyway?
 - should we have an opt-out or even opt-in for guard tag verification
   to avoid the higher level code tripping up on returned errors where
   they just want to check if a signature matches?