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?
