linux-kernel - Re: [PATCH stable/6.18-6.17] md: add check_new

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251217223130.1c571fa5@nvm>
Date: Wed, 17 Dec 2025 22:31:30 +0500
From: Roman Mamedov <rm@...anrm.net>
To: "Yu Kuai" <yukuai@...as.com>
Cc: "Greg KH" <gregkh@...uxfoundation.org>, <linan666@...weicloud.com>,
 <stable@...r.kernel.org>, <song@...nel.org>, <linux-raid@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>, <yangerkun@...wei.com>,
 <yi.zhang@...wei.com>
Subject: Re: [PATCH stable/6.18-6.17] md: add check_new_feature module
 parameter

On Thu, 18 Dec 2025 01:11:43 +0800
"Yu Kuai" <yukuai@...as.com> wrote:

> Hi,
> 
> 在 2025/12/17 22:04, Greg KH 写道:
> > On Wed, Dec 17, 2025 at 09:05:13PM +0800, linan666@...weicloud.com wrote:
> >> From: Li Nan <linan122@...wei.com>
> >>
> >> commit 9c47127a807da3e36ce80f7c83a1134a291fc021 upstream.
> >>
> >> Raid checks if pad3 is zero when loading superblock from disk. Arrays
> >> created with new features may fail to assemble on old kernels as pad3
> >> is used.
> >>
> >> Add module parameter check_new_feature to bypass this check.
> > This is a new feature, why does it need to go to stable kernels?
> >
> > And a module parameter?  Ugh, this isn't the 1990's anymore, this is not
> > good and will be a mess over time (think multiple devices...)
> 
> Nan didn't mention the background. We won't backport the new feature to stable
> kernels(Although this fix a data lost problem in the case array is created
> with disks in different lbs, anyone is interested can do this). However, this
> backport is just used to provide a possible solution for user to still assemble
> arrays after switching to old LTS kernels when they are using the default lbs.

This is still a bad scenario. Original problem:

- Boot into a new kernel once, reboot into the old one, the existing array no
  longer works.

After this patch:

- Same. Unless you know how, where and which module parameter to add, to
  be passed to md module on load. Might be not convenient if the root FS
  didn't assemble and mount and is inaccessible.

Not ideal whatsoever.

Wouldn't it be possible to implement minimal *automatic* recognition (and
ignoring) of those newly utilized bits instead?

-- 
With respect,
Roman