Re: [PATCH stable/6.18-6.17] md: add check_new_feature module parameter

[Li Nan <linan666@huaweicloud.com>]

在 2025/12/18 15:14, Greg KH 写道:
> 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@fnnas.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> 在 2025/12/17 22:04, Greg KH 写道:
>>>>>> On Wed, Dec 17, 2025 at 09:05:13PM +0800, linan666@huaweicloud.com wrote:
>>>>>>> From: Li Nan <linan122@huawei.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
> 
> .

I'm finalizing and testing the patch now and will send it out shortly.

Sorry for any inconvenience caused.

-- 
Thanks,
Nan