From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Max Gurtovoy <mgurtovoy@nvidia.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
hch@lst.de, sagi@grimberg.me, linux-nvme@lists.infradead.org,
hare@suse.de, kbusch@kernel.org, axboe@kernel.dk,
linux-block@vger.kernel.org, oren@nvidia.com, oevron@nvidia.com,
israelr@nvidia.com
Subject: Re: [PATCH v2 2/2] nvme-multipath: fix path failover for integrity ns
Date: Tue, 25 Apr 2023 21:22:33 -0400 [thread overview]
Message-ID: <yq1y1mfihx3.fsf@ca-mkp.ca.oracle.com> (raw)
In-Reply-To: <85974694-c544-be82-97ce-c318adacda49@nvidia.com> (Max Gurtovoy's message of "Tue, 25 Apr 2023 13:24:31 +0300")
Hi Max!
> The way I see it now, and I might be wrong, is that the Linux kernel
> is not supporting application to store apptag values unless it's using
> some passthrough command.
As Keith mentioned, there are various ways.
But let's assume you are a multipathed storage device that says "Yes, I
support encryption". And then one of the paths doesn't and just lets
things go across the wire in plain text.
I think most people would agree that would be a *bad* thing.
The expectation is that when a device reports that a capability is
enabled, that this capability is actually effective. Protection
information is no different. The PI is part of the data and it needs to
be validated by the recipient.
Silently throwing away the protection information defies the very
premise of why data integrity protection was defined in the first place.
--
Martin K. Petersen Oracle Linux Engineering
prev parent reply other threads:[~2023-04-26 1:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-24 22:54 [PATCH v2 0/2] Fix failover to non integrity NVMe path Max Gurtovoy
2023-04-24 22:54 ` [PATCH v2 1/2] block: bio-integrity: export bio_integrity_free func Max Gurtovoy
2023-04-24 22:54 ` [PATCH v2 2/2] nvme-multipath: fix path failover for integrity ns Max Gurtovoy
2023-04-25 2:12 ` Martin K. Petersen
2023-04-25 10:24 ` Max Gurtovoy
2023-04-25 22:39 ` Keith Busch
2023-04-26 1:22 ` Martin K. Petersen [this message]
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=yq1y1mfihx3.fsf@ca-mkp.ca.oracle.com \
--to=martin.petersen@oracle.com \
--cc=axboe@kernel.dk \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=israelr@nvidia.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=mgurtovoy@nvidia.com \
--cc=oevron@nvidia.com \
--cc=oren@nvidia.com \
--cc=sagi@grimberg.me \
/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