linux-kernel - Re: [regression] Bug 217074 - upgrading to kernel 6.1.12 from 5.15.x can no longer assemble software raid0

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 8 Mar 2023 09:55:42 +0100
From:   Mariusz Tkaczyk <mariusz.tkaczyk@...ux.intel.com>
To:     "NeilBrown" <neilb@...e.de>
Cc:     "Song Liu" <song@...nel.org>,
        "Linux regressions mailing list" <regressions@...ts.linux.dev>,
        Jes.Sorensen@...il.com, "linux-raid" <linux-raid@...r.kernel.org>,
        "LKML" <linux-kernel@...r.kernel.org>,
        "Nikolay Kichukov" <hijacker@...um.net>
Subject: Re: [regression] Bug 217074 - upgrading to kernel 6.1.12 from
 5.15.x can no longer assemble software raid0

On Wed, 08 Mar 2023 09:33:52 +1100
"NeilBrown" <neilb@...e.de> wrote:

> On Tue, 07 Mar 2023, Mariusz Tkaczyk wrote:
> > On Mon, 06 Mar 2023 08:21:07 +1100
> > "NeilBrown" <neilb@...e.de> wrote:
> >   
> > > On Sat, 04 Mar 2023, Song Liu wrote:  
> > > > + Jes.
> > > > 
> > > > It appeared to me that we can assemble the array if we have any of the
> > > > following:
> > > > 1. Enable CONFIG_BLOCK_LEGACY_AUTOLOAD;
> > > > 2. Have a valid /etc/mdadm.conf;
> > > > 3. Update mdadm to handle this case. (I tried some ugly hacks, which
> > > > worked but weren't clean).
> > > > 
> > > > Since we eventually would like to get rid of
> > > > CONFIG_BLOCK_LEGACY_AUTOLOAD, I think we need mdadm to handle this
> > > > properly. But the logistics might be complicated, as
> > > > mdadm are shipped separately.
> > > > 
> > > > Jes, what do you think about this? AFAICT, we need to update the logic
> > > > in mdopen.c:create_mddev().    
> > > 
> > > mdadm already handles this, but only if 
> > >    CREATE names=yes
> > > is present in /etc/mdadm.conf  
> > 
> > Hi,
> > 
> > "CREATE names=yes" enforces creation of /dev/md_name arrays instead of
> > /dev/mdXXX. It is a large change for users, too aggressive IMO. It will
> > destroy many setups.
> > 
> > To resolve it, we need is to use create_named_array() but respect old naming
> > convention. We already have find_free_devnm(), and we are able to keep
> > consistency because we can create 'mdXXX':
> > 
> > /sys/module/md_mod/parameters # echo md125 > new_array
> > 
> > /sys/module/md_mod/parameters # ll /sys/block/md125
> > lrwxrwxrwx 1 root root 0 Mar  7 10:54 /sys/block/md125 ->
> > ../devices/virtual/block/md125
> > 
> > That will require adjustments in mdadm, but I think that we can keep
> > names the same way. I created the test for verification of base creation
> > flows, we can use it to avoid regression:
> > https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/tests/00createnames
> > 
> > Thoughts?  
> 
> Yes, that is probably sensible.
> 
> It would be nice to have a way to expose the "names=yes" functionality
> more obviously.  I think people would generally prefer it (/proc/mdstat
> becomes more meaningful) but I agree that forcing it on people is the
> the best approach.
> 
> Maybe a super-block flag that enables it for that array, and we start
> setting that flag when creating new arrays?
> 

That is controversial. I don't feel that using metadata to resolve Linux issue
is as a good way. It will work for native for sure but for IMSM it is not such
simple.

I think that we can handle it by config file.
When we set "ARRAY /dev/mdXXX" then it is honored. I'm familiar with such
cases, that works. In such case link may or may not be generated so far I
remember but... nobody cares if array name is meaningful and we can fix that
too. It seems to not be a big deal.

I would like to propose doing same for 'names'.
If there is no config or name is set to "/dev/md/name" it should work as now.
So, if someone would need backward compatibility we can add flag to --detail
and --examine breifs forces that, let say --use-link-as-name. By default
"ARRAY /dev/md_name" entry will be generated.

My PoV is based on IMSM, there may be small differences between IMSM and native
but I think that it applies everywhere.

Thanks,
Mariusz