[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <6979cd43-d38c-477d-857c-8d211bc85474@fnnas.com>
Date: Thu, 18 Dec 2025 01:11:43 +0800
From: "Yu Kuai" <yukuai@...as.com>
To: "Greg KH" <gregkh@...uxfoundation.org>, <linan666@...weicloud.com>
Cc: <stable@...r.kernel.org>, <song@...nel.org>,
<linux-raid@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<yangerkun@...wei.com>, <yi.zhang@...wei.com>, <yukuai@...as.com>
Subject: Re: [PATCH stable/6.18-6.17] md: add check_new_feature module parameter
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.
I think this is fine to provide forward compatibility, please let us know if you
do not like this, or Nan should send a new version with explanation.
>
> thanks,
>
> greg k-h
>
--
Thansk,
Kuai
Powered by blists - more mailing lists