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] [thread-next>] [day] [month] [year] [list]

Message-ID: <2025121849-moonlit-emotion-41ed@gregkh>
Date: Thu, 18 Dec 2025 08:14:00 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Li Nan <linan666@...weicloud.com>
Cc: Roman Mamedov <rm@...anrm.net>, Yu Kuai <yukuai@...as.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, Dec 18, 2025 at 02:57:23PM +0800, Li Nan wrote:
> 
> 
> 在 2025/12/18 14:30, Greg KH 写道:
> > 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
> > 
> > .
> 
> We propose the following fix for this issue. After fix, md arrays created
> on old kernels won't be affected by this feature.
> 
> https://lore.kernel.org/linux-raid/825e532d-d1e1-44bb-5581-692b7c091796@huaweicloud.com/T/#mb205fb97ab4af629cae9db8dfd236ceaa93f14ad
> 
> The method is:
> > only set lbs by default for new array, for assembling the array still
> > left the lbs field unset, in this case the data loss problem is not fixed,
> > we should also print a warning and guide users to set lbs to fix the
> problem,
> > with the notification the array will not be assembled in old kernels.

Great, have a patch for this?

thanks,

greg k-h