From: Christoph Hellwig <hch@lst.de>
To: Kanchan Joshi <joshi.k@samsung.com>,
Anuj Gupta <anuj20.g@samsung.com>,
"Martin K . Petersen" <martin.petersen@oracle.com>
Cc: linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-nvme@lists.infradead.org
Subject: fine-grained PI control
Date: Fri, 5 Jul 2024 10:32:04 +0200 [thread overview]
Message-ID: <20240705083205.2111277-1-hch@lst.de> (raw)
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?
next reply other threads:[~2024-07-05 8:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-05 8:32 Christoph Hellwig [this message]
2024-07-08 14:17 ` fine-grained PI control Anuj gupta
2024-07-09 7:08 ` Christoph Hellwig
2024-07-09 3:35 ` Martin K. Petersen
2024-07-09 7:16 ` Christoph Hellwig
2024-07-10 3:47 ` Martin K. Petersen
2024-07-11 5:42 ` Christoph Hellwig
2024-07-16 2:07 ` Martin K. Petersen
2024-07-26 10:21 ` Anuj Gupta
2024-07-29 17:03 ` Christoph Hellwig
2024-09-18 6:39 ` Anuj Gupta
2024-09-24 1:59 ` Martin K. Petersen
2024-09-24 5:36 ` Christoph Hellwig
2024-09-27 2:01 ` Martin K. Petersen
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=20240705083205.2111277-1-hch@lst.de \
--to=hch@lst.de \
--cc=anuj20.g@samsung.com \
--cc=joshi.k@samsung.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/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