All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: <stable@vger.kernel.org>
Cc: <songliubraving@fb.com>, <neilb@suse.de>,
	<guoqing.jiang@cloud.ionos.com>
Subject: Please backport 33f2c35a54df to kernels containing c84a1372df92 for raid0 compatibility
Date: Wed, 24 Jun 2020 12:49:31 -0400	[thread overview]
Message-ID: <20200624164931.GA15350@windriver.com> (raw)

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.

             reply	other threads:[~2020-06-24 16:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24 16:49 Paul Gortmaker [this message]
2020-06-25  1:44 ` Please backport 33f2c35a54df to kernels containing c84a1372df92 for raid0 compatibility Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200624164931.GA15350@windriver.com \
    --to=paul.gortmaker@windriver.com \
    --cc=guoqing.jiang@cloud.ionos.com \
    --cc=neilb@suse.de \
    --cc=songliubraving@fb.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.