On 25/04/2023 5:12, Martin K. Petersen wrote:
Hi Max!
In case the integrity capabilities of the failed path and the failover
path don't match, we may run into NULL dereference. Free the integrity
context during the path failover and let the block layer prepare it
again if needed during bio_submit.
This assumes that the protection information is just an ephemeral
checksum. However, that is not always the case. The application may
store values in the application or storage tags which must be returned
on a subsequent read.
Interesting.
Maybe you can point me to this API that allow applications to store
application tag in PI field ?
I see that app_tag is 0 in Linux and we don't set the nvme_cmd->apptag
to non zero value.
It's been a while since I was working on this so I might be wrong here :).
I've noticed that in t10_pi_generate and ext_pi_crc64_generate we set it
to 0 as well.
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.
In addition, in some overseas markets (financial, government), PI is a
regulatory requirement. It would be really bad for us to expose a device
claiming PI support and then it turns out the protection isn't actually
always active.
DM multipathing doesn't allow mismatched integrity profiles. I don't
think NVMe should either.
AFAIU, the DM multipath is not a specification but a Linux
implementation. NVMe multipathing follows a standard.
