From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1q6aSd-0000Yg-8p for mharc-grub-devel@gnu.org; Tue, 06 Jun 2023 13:27:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6aSY-0000YC-9g for grub-devel@gnu.org; Tue, 06 Jun 2023 13:27:09 -0400 Received: from smtp-relay-internal-0.canonical.com ([185.125.188.122]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6aSV-0002K7-PU for grub-devel@gnu.org; Tue, 06 Jun 2023 13:27:06 -0400 Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 6A8E03F14A for ; Tue, 6 Jun 2023 17:27:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1686072420; bh=QIdqk+UP5MYFOzg0oXzw9fVInjfhXCHI5xDH2x01Z5E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=jAOOqBX3uJI0blIxV7c3AGa18Q7UF71LV2/sEy1lsMZXAb7yXR5kkQir+8cNZPTSD 96Kk0q3eI0DNb5UjAqPnDcIct2Ot4UdYN2xDEiGjPW+w7ar+oHhqoFvOn6bhrtvN88 5Rg40UXPEpzYNmJn01Ee2R3/mvYQeHXSuC/rK+THvgrGOviCipNlmbLmHxmiAyI10s PVB2Mn1JaanDp8Yl5gX4Cw6i9X5wCzBdgJIxd+cnabppCaf9upHjsjPn+TgeG1oyaP Ybsu4tPxdavv5V7DH5gNeG7vbfAhIk2GdnT3T7zdVy1rqHP1q4P1s+m/u4oY7m8F9x WRESwJLrBW6EA== Received: by mail-ed1-f72.google.com with SMTP id 4fb4d7f45d1cf-5162cdaa255so4096711a12.1 for ; Tue, 06 Jun 2023 10:27:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686072420; x=1688664420; h=in-reply-to:content-disposition:mime-version:references :accept-language:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QIdqk+UP5MYFOzg0oXzw9fVInjfhXCHI5xDH2x01Z5E=; b=Y86fqCsjFz3iZm1luTyg717Kwvy//eCHsHZFXZ7RsF2s9y3ZxzEnFa7asg6LyshhS5 Hbf/nScPW6x+svUoSCYBDwFG6P9myXIMkzGpJEiF1dcY2jt3VzEQhzRarxbZjwWQWe9Z OXFGTdMW/Hci8n4NMTsBqNtKI7PYY2OU7kDKvQL2ASevDUmHkY5fEr0Pf66NwblAjG62 iYrBBvesycPW8Hi4rwVgFO37k9lxI0dbVscirxR6WWhhePGLoTaOWllpMdAnfvdJiiHi d2rTkLl8BCs2EVB5IAe5C4VVB+xONwJvBIzpnbKdXlcfZcTjpOhJtX9jdCNYw6jjpKUe GRvg== X-Gm-Message-State: AC+VfDw9wmqnN6TsqTtp+On2ud66WAWW2abuijJZrI+2TqK7TDLo1cvx nm80N6keu2UKQN2emIt3/80yNH+nW5CJOv+izCTVBd55qfjx0c3bnHrZapJ6EeasQfduNL2cNmD Lx22C+OHTgZ4r9PTUiI0O6rTzHR2h X-Received: by 2002:a17:907:d8a:b0:974:1839:11f2 with SMTP id go10-20020a1709070d8a00b00974183911f2mr4046995ejc.0.1686072420103; Tue, 06 Jun 2023 10:27:00 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4wwzFvBElkI9+95GBMcWO5QGEfslLc58/pbMQqpGHEHP3DTOgUzuTTRRo7JYyGTDC4mzGzmQ== X-Received: by 2002:a17:907:d8a:b0:974:1839:11f2 with SMTP id go10-20020a1709070d8a00b00974183911f2mr4046984ejc.0.1686072419741; Tue, 06 Jun 2023 10:26:59 -0700 (PDT) Received: from jak-t14-g3 ([2a02:908:2812:7d20::e336]) by smtp.gmail.com with ESMTPSA id u26-20020a1709060b1a00b00977d7bd9069sm3138822ejg.179.2023.06.06.10.26.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Jun 2023 10:26:59 -0700 (PDT) Date: Tue, 6 Jun 2023 19:26:57 +0200 From: Julian Andres Klode To: Daniel Kiper Cc: The development of GNU GRUB , Kees Cook , Kees Cook Subject: Re: [PATCH] osdep/linux: Fix md array device enumeration Message-ID: <20230606172657.574yzsfgsq624k4i@jak-t14-g3> Accept-Language: de-DE, de, en-GB, en-US, en References: <20230606161020.2337550-1-julian.klode@canonical.com> <20230606161527.wlq4bhz7kg3qabpy@jak-t14-g3> <20230606170926.7lawabajepyppt7v@tomti.i.net-space.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230606170926.7lawabajepyppt7v@tomti.i.net-space.pl> Received-SPF: pass client-ip=185.125.188.122; envelope-from=julian.klode@canonical.com; helo=smtp-relay-internal-0.canonical.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2023 17:27:09 -0000 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: > > > From: Kees Cook > > > > > > GET_ARRAY_INFO's info.nr_disks does not map to GET_DISK_INFO's > > > disk.number, which is an internal kernel index. If an array has had drives > > > added, removed, etc, there may be gaps in GET_DISK_INFO's results. But > > > since the consumer of devicelist cannot tolerate gaps (it expects to walk > > > a NULL-terminated list of device name strings), the devicelist index (j) > > > must be tracked separately from the disk.number index (i). But grub > > > wants to only examine active (i.e. present and non-failed) disks, so how > > > many disks are left to be queried must be also separately tracked > > > (remaining). > > > > > > Fixes: 49de079bbe1c ("... (grub_util_raid_getmembers): Handle "removed" disks") > > > Fixes: 2b00217369ac ("... Added support for RAID and LVM") > > > Fixes: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1912043 > > > Fixes: https://savannah.gnu.org/bugs/index.php?59887 > > > Signed-off-by: Kees Cook > > > > I did not add a cover letter, I just found this patch in a merge request > > on Debian's GitLab, and it still applies, but I haven't tested it > > further than Kees did, and don't know what the test case is quite > > honestly. > > This patch is in upstream as commit c39f27cd6 (osdep/linux: Fix md array > device enumeration). Huh sorry, I must have been looking at a wrong branch and applied to a wrong branch before forwarding. > > 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 -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en