Re: [PATCH stable/6.18-6.17] md: add check_new_feature module parameter
Li Nan <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.kernel.stable,gmane.linux.raid |
|---|---|
| Message-ID | <[email protected]> |
在 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" <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> 在 2025/12/17 22:04, Greg KH 写道: >>>>>> On Wed, Dec 17, 2025 at 09:05:13PM +0800, [email protected] wrote: >>>>>>> From: Li Nan <[email protected]> >>>>>>> >>>>>>> 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/[email protected]/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