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: <CALTww2_hu3uocnYvJTViL88A30WgVPHs3-ZHgQYK2qgB0S9b7w@mail.gmail.com>
Date: Mon, 10 Nov 2025 10:26:45 +0800
From: Xiao Ni <xni@...hat.com>
To: yukuai@...as.com
Cc: Li Nan <linan666@...weicloud.com>, corbet@....net, song@...nel.org, hare@...e.de, 
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-raid@...r.kernel.org, yangerkun@...wei.com, yi.zhang@...wei.com
Subject: Re: [PATCH v9 4/5] md: add check_new_feature module parameter

On Fri, Nov 7, 2025 at 1:06 AM Yu Kuai <yukuai@...as.com> wrote:
>
> Hi,
>
> 在 2025/11/6 22:56, Xiao Ni 写道:
> > On Thu, Nov 6, 2025 at 9:31 PM Yu Kuai <yukuai@...as.com> wrote:
> >> Hi,
> >>
> >> 在 2025/11/6 21:15, Xiao Ni 写道:
> >>> In patch05, the commit says this:
> >>>
> >>> Future mdadm should support setting LBS via metadata field during RAID
> >>> creation and the new sysfs. Though the kernel allows runtime LBS changes,
> >>> users should avoid modifying it after creating partitions or filesystems
> >>> to prevent compatibility issues.
> >>>
> >>> So it only can specify logical block size when creating an array. In
> >>> the case you mentioned above, in step3, the array will be assembled in
> >>> new kernel and the sb->pad3 will not be set, right?
> >> No, lbs will be set to the value array actually use in metadata, otherwise
> >> data loss problem will not be fixed for the array with different lbs from
> >> underlying disks, this is what we want to fix in the first place.
> > But the case you mentioned is to assemble an existing array in a new
> > kernel. The existing array in the old kernel doesn't set lbs. So the
> > sb->pad3 will be zero when assembling it in the new kernel.
>
> Looks like you misunderstood the patch, lbs in sb->pad3 will be updated to the
> real lbs when array is assembled in the new kernel. Set lbs in metadata is
> necessary to avoid data loss.
>
> And please noted this patch is required to be backported to old kernel to
> make it possible that array with default lbs can be assembled again in old
> kernel.

Thanks for the explanation. The patch looks good to me.
Reviewed-by: Xiao Ni <xni@...hat.com>

Regards
Xiao
>
> >
> > And as planned, we will not support --lbs (for example) for the `mdadm
> > --assemble` command.
> >
> > The original problem should be fixed by specifying lbs when creating
> > an array (https://www.spinics.net/lists/raid/msg80870.html). Maybe we
> > should avoid updating lbs when adding a new disk?
>
> I don't understand, lbs modification should be forbidden once array is
> created, it's only allowed to be updated before the array is running the
> first time.
>
> >
> > Regards
> > Xiao
> >> Thanks,
> >> Kuai
> >>
>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ