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: <c34450ca-7359-7be0-1266-133a71f6c579@huaweicloud.com>
Date: Thu, 18 Dec 2025 14:57:23 +0800
From: Li Nan <linan666@...weicloud.com>
To: Greg KH <gregkh@...uxfoundation.org>, 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



在 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.

-- 
Thanks,
Nan