Re: [PATCH] osdep/linux: Fix md array device enumeration

[Kees Cook]

On Wed, Jun 07, 2023 at 03:39:24PM +0200, Daniel Kiper wrote:
> On Tue, Jun 06, 2023 at 11:02:31AM -0700, Kees Cook wrote:
> > On Tue, Jun 6, 2023 at 10:27 AM Julian Andres Klode
> > <julian.klode@canonical.com> wrote:
> > >
> > > On Tue, Jun 06, 2023 at 07:09:26PM +0200, Daniel Kiper wrote:
> > > > On Tue, Jun 06, 2023 at 06:15:27PM +0200, Julian Andres Klode wrote:
> > > > > On Tue, Jun 06, 2023 at 06:10:21PM +0200, Julian Andres Klode wrote:
> > > > [...]
> > > > This patch is in upstream as commit c39f27cd6 (osdep/linux: Fix md array
> > > > device enumeration).
> >
> > Oh good. I really thought it had landed already, so thanks for
> > checking. I got worried this morning when I saw the email to
> > grub-devel. :P "Wasn't that fixed already?" :) But thank you for
> > making sure it hadn't gotten lost! Is there a way to close the tracker
> > item for it?
> 
> I think you should be able to do that.

Ah-ha, yes, I've closed it now. :)
https://salsa.debian.org/grub-team/grub/-/merge_requests/23

> 
> > > [...]
> > > > I realized right now that MD_MAX_DISKS defined in commit c39f27cd6
> > > > (osdep/linux: Fix md array device enumeration) is not in sync with
> > > > commit 2a5e3c1f2 (disk/diskfilter: Don't make a RAID array with more
> > > > than 1024 disks). I think we should sync both numbers down to 1024...
> > >
> > > +1
> >
> > Yeah, seems reasonable, though as I hinted in the original patch, this
> > number appeared to have been arbitrarily chosen by mdadm at the time.
> 
> OK, we will bump it to 4096 as well.

Yeah, I think _technically_ it can be higher than 1024, though ... I
struggle to imagine this for a boot device. ;)

-- 
Kees Cook