stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Please backport 33f2c35a54df to kernels containing c84a1372df92 for raid0 compatibility
@ 2020-06-24 16:49 Paul Gortmaker
  2020-06-25  1:44 ` Sasha Levin
  0 siblings, 1 reply; 2+ messages in thread
From: Paul Gortmaker @ 2020-06-24 16:49 UTC (permalink / raw)
  To: stable; +Cc: songliubraving, neilb, guoqing.jiang

Hi all,

I'm recommending backporting commit 33f2c35a54dfd75ad0e7e86918dcbe4de799a56c
("md: add feature flag MD_FEATURE_RAID0_LAYOUT") to any stable kernels with
commit c84a1372df929033cb1a0441fb57bd3932f39ac9 ("md/raid0: avoid RAID0
data corruption due to layout confusion.")

Here is why.  As part of the various recommended mitigation pages out
there, we'll see instructions indicating that using a newer mdadm can
allow one to avoid using the raid0.layout= boot argument.

However, if one does that on a kernel that does *not* contain 33f2c,
then such an older kernel will be "locked out" from mounting the volume
because this test will fail:

	(le32_to_cpu(sb->feature_map) & ~MD_FEATURE_ALL) != 0)

...since the on-disk sb now has MD_FEATURE_RAID0_LAYOUT but the older
kernel knows nothing about it and you get EINVAL (-22) during mount.

I ran into the above situation on a v5.2 kernel, and backporting the
33f2c resolved the locked out issue, and then the bootarg was no longer
required, as documented by the updated mdadm man page.

Thanks,
Paul.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Please backport 33f2c35a54df to kernels containing c84a1372df92 for raid0 compatibility
  2020-06-24 16:49 Please backport 33f2c35a54df to kernels containing c84a1372df92 for raid0 compatibility Paul Gortmaker
@ 2020-06-25  1:44 ` Sasha Levin
  0 siblings, 0 replies; 2+ messages in thread
From: Sasha Levin @ 2020-06-25  1:44 UTC (permalink / raw)
  To: Paul Gortmaker; +Cc: stable, songliubraving, neilb, guoqing.jiang

On Wed, Jun 24, 2020 at 12:49:31PM -0400, Paul Gortmaker wrote:
>Hi all,
>
>I'm recommending backporting commit 33f2c35a54dfd75ad0e7e86918dcbe4de799a56c
>("md: add feature flag MD_FEATURE_RAID0_LAYOUT") to any stable kernels with
>commit c84a1372df929033cb1a0441fb57bd3932f39ac9 ("md/raid0: avoid RAID0
>data corruption due to layout confusion.")
>
>Here is why.  As part of the various recommended mitigation pages out
>there, we'll see instructions indicating that using a newer mdadm can
>allow one to avoid using the raid0.layout= boot argument.
>
>However, if one does that on a kernel that does *not* contain 33f2c,
>then such an older kernel will be "locked out" from mounting the volume
>because this test will fail:
>
>	(le32_to_cpu(sb->feature_map) & ~MD_FEATURE_ALL) != 0)
>
>...since the on-disk sb now has MD_FEATURE_RAID0_LAYOUT but the older
>kernel knows nothing about it and you get EINVAL (-22) during mount.
>
>I ran into the above situation on a v5.2 kernel, and backporting the
>33f2c resolved the locked out issue, and then the bootarg was no longer
>required, as documented by the updated mdadm man page.

33f2c35a54df ("md: add feature flag MD_FEATURE_RAID0_LAYOUT") was queued
for the 4.19 and 4.14 branches, thank you!

-- 
Thanks,
Sasha

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-06-25  1:44 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-06-24 16:49 Please backport 33f2c35a54df to kernels containing c84a1372df92 for raid0 compatibility Paul Gortmaker
2020-06-25  1:44 ` Sasha Levin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).