On Tue, Apr 25, 2023 at 01:24:31PM +0300, Max Gurtovoy wrote: > > > 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 think Martin might be considering kernel modules as apps since they can access the integrity payload no problem. I know of at least one out-of-tree module (ex: OpenCAS) that utilizes the apptag (not that upstream necessarily should care about such modules..). Outside that, passthrough ioctls and io_uring_cmd can access the fields. I don't think those interfaces apply to what you're changing, though, since these bypass the submit_bio() interface. > 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. If we're considering only in-tree usage, I think you're correct. > > 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. If we're talking about any of the nvme passthrough interfaces, which format will the user space need to construct its command for? This seems confusing since userspace doesn't have direct control over which path the command will be dispatched on, so it won't know which format it needs to cater to, nor will it have deterministic behavior.
