Re: [PATCH v2 2/2] nvme-multipath: fix path failover for integrity ns

[Max Gurtovoy <mgurtovoy@nvidia.com>]

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.