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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <8f5ce378-9a83-454b-5b92-df530308c679@trained-monkey.org>
Date:   Tue, 7 Mar 2023 14:44:24 -0500
From:   Jes Sorensen <jes@...ined-monkey.org>
To:     Mariusz Tkaczyk <mariusz.tkaczyk@...ux.intel.com>,
        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 3/7/23 03:52, 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.

This is my concern too. I find a lot of people setup their box with md
and then keep it running, but they don't necessarily update it as
frequently as their laptop etc. This could cause some unpleasant
surprises down the road.

> 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?

I like this.

> BTW. I wanted to get rid of this legacy "create_on_open" from mdadm anyway but
> never had time to. If you agree, I can proceed with fixing it.

Oh yes

Cheers,
Jes