[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2025121800-doorframe-enviably-56d5@gregkh>
Date: Thu, 18 Dec 2025 07:30:25 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Roman Mamedov <rm@...anrm.net>
Cc: Yu Kuai <yukuai@...as.com>, 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 Wed, Dec 17, 2025 at 10:31:30PM +0500, Roman Mamedov wrote:
> 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?
Yes, that should be done instead.
And again, a module parameter does not work for multiple devices in a
system, the upstream change should also be reverted.
thanks,
greg k-h
Powered by blists - more mailing lists