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: <20241112085327.00007de3@linux.intel.com>
Date: Tue, 12 Nov 2024 08:54:31 +0100
From: Mariusz Tkaczyk <mariusz.tkaczyk@...ux.intel.com>
To: Song Liu <song@...nel.org>
Cc: Yu Kuai <yukuai1@...weicloud.com>, linux-raid@...r.kernel.org,
 linux-kernel@...r.kernel.org, yi.zhang@...wei.com, yangerkun@...wei.com,
 "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH md-6.13] md: remove bitmap file support

On Thu, 7 Nov 2024 17:28:43 -0800
Song Liu <song@...nel.org> wrote:

> On Thu, Nov 7, 2024 at 5:03 PM Yu Kuai <yukuai1@...weicloud.com> wrote:
> >
> > Hi,
> >
> > 在 2024/11/08 7:41, Song Liu 写道:  
> > > On Thu, Nov 7, 2024 at 5:02 AM Yu Kuai <yukuai1@...weicloud.com> wrote:  
> > >>
> > >> From: Yu Kuai <yukuai3@...wei.com>
> > >>
> > >> The bitmap file has been marked as deprecated for more than a year now,
> > >> let's remove it, and we don't need to care about this case in the new
> > >> bitmap.
> > >>
> > >> Signed-off-by: Yu Kuai <yukuai3@...wei.com>  
> > >
> > > What happens when an old array with bitmap file boots into a kernel
> > > without bitmap file support?  
> >
> > If mdadm is used with bitmap file support, then kenel will just ignore
> > the bitmap, the same as none bitmap. Perhaps it's better to leave a
> > error message?  
> 
> Yes, we should print some error message before assembling the array.
> 
> > And if mdadm is updated, reassemble will fail.  

I would be great if mdadm can just ignore it too. It comes from config file, so
simply you can ignore bitmap entry if it is different than "internal" or
"clustered". You can print error however you must do it somewhere else (outside
config.c), otherwise user would be always prompted about that on every config
read - probably we don't need to make it such noise but maybe we should (user
may not notice change if we are not screaming it loud). I have no opinion here.

The first rule is always data access- we should not break that if possible. I
think case I think it is possible to keep them assembled.

> 
> I think we should ship this with 6.14 (not 6.13), so that we have
> more time testing different combinations of old/new mdadm
> and kernel. WDYT?

Later is better because it decreases possibility that someone would met the
case with new kernel and old mdadm, where probably some ioctl/sysfs writes
fails will be observed.

I would say that we should wait around one year after removing it from mdadm.
That is preferred by me.

I will merge Kuai changes soon, before the release. I think it is valuable to
have it blocked in new mdadm release.

Mariusz

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ