Re: [PATCH 5.4 26/34] dm verity: set DM_TARGET_IMMUTABLE feature flag

[Oleksandr Tymoshenko <ovt@google.com>]

On Thu, Jun 9, 2022 at 10:15 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Jun 10, 2022 at 04:22:00AM +0000, Oleksandr Tymoshenko wrote:
> > I believe this commit introduced a regression in dm verity on systems
> > where data device is an NVME one. Loading table fails with the
> > following diagnostics:
> >
> > device-mapper: table: table load rejected: including non-request-stackable devices
> >
> > The same kernel works with the same data drive on the SCSI interface.
> > NVME-backed dm verity works with just this commit reverted.
> >
> > I believe the presence of the immutable partition is used as an indicator
> > of special case NVME configuration and if the data device's name starts
> > with "nvme" the code tries to switch the target type to
> > DM_TYPE_NVME_BIO_BASED (drivers/md/dm-table.c lines 1003-1010).
> >
> > The special NVME optimization case was removed in
> > 5.10 by commit 9c37de297f6590937f95a28bec1b7ac68a38618f, so only 5.4 is
> > affected.
> >
>
> Why wouldn't 4.9, 4.14, and 4.19 also be affected here?

Just a bad choice of words on my side: we use only 5.x branches and
it slipped my mind to verify all actively supported branches. 4.19 is likely
to be affected, it has the same code for the NVME optimization as 5.4.
4.9 and 4.14 doesn't  this code so probably not affected.

> Should I also
> just queue up 9c37de297f65 ("dm: remove special-casing of bio-based
> immutable singleton target on NVMe") to those older kernels?  If so,
> have you tested this and verified that it worked?

I don't have enough expertise in this domain to recommend a solution, that's
why I reported the problem instead of sending a patch. I did take a quick look
though: it doesn't apply cleanly and it seems that the 9c37de297f65 was removed
as a result of some other refactoring, so I think it's more complex
than backporting
a single commit.

>
> thanks,
>
> greg k-h