linux-kernel - RE: [PATCH v2] apei/ghes: correctly return NULL for ghes_get

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: <DBBPR08MB45386D3C1E4958A36FDA781BF7469@DBBPR08MB4538.eurprd08.prod.outlook.com>
Date:   Thu, 25 May 2023 15:17:34 +0000
From:   Justin He <Justin.He@....com>
To:     Li Yang <leoyang.li@....com>, Toshi Kani <toshi.kani@....com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>, James Morse <James.Morse@....com>,
        Tony Luck <tony.luck@...el.com>, Borislav Petkov <bp@...en8.de>
CC:     "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2] apei/ghes: correctly return NULL for
 ghes_get_devices()

Hi Li,

> -----Original Message-----
> From: Li Yang <leoyang.li@....com>
> Sent: Saturday, May 20, 2023 4:13 AM
> To: Rafael J. Wysocki <rafael@...nel.org>; Len Brown <lenb@...nel.org>;
> James Morse <James.Morse@....com>; Tony Luck <tony.luck@...el.com>;
> Borislav Petkov <bp@...en8.de>; Justin He <Justin.He@....com>
> Cc: Li Yang <leoyang.li@....com>; linux-acpi@...r.kernel.org;
> linux-kernel@...r.kernel.org
> Subject: [PATCH v2] apei/ghes: correctly return NULL for ghes_get_devices()
>
> Since 315bada690e0 ("EDAC: Check for GHES preference in the chipset-specific
> EDAC drivers"), vendor specific EDAC driver will not probe correctly when
> CONFIG_ACPI_APEI_GHES is enabled but no GHES device is present.  Make
> ghes_get_devices() return NULL when the GHES device list is empty to fix the
> problem.
>
> Fixes: 9057a3f7ac36 ("EDAC/ghes: Prepare to make ghes_edac a proper
> module")
> Signed-off-by: Li Yang <leoyang.li@....com>
> Cc: Jia He <justin.he@....com>
> ---
>
> V2: fix the fallthrough case in x86 path
>
>  drivers/acpi/apei/ghes.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index
> 34ad071a64e9..4382fe13ee3e 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -1544,6 +1544,8 @@ struct list_head *ghes_get_devices(void)
>
>                       pr_warn_once("Force-loading ghes_edac on an unsupported
> platform. You're on your own!\n");
>               }
> +     } else if (list_empty(&ghes_devs)) {
> +             return NULL;
>       }
I have no major objections to the fix. Just curious about the edac driver in you platform.
IIUC, in your case, CONFIG_ACPI_APEI_GHES is enabled and edac_ghes driver is either not
loaded or fails to load. Is my understanding correct?
I wonder whether ghes_get_devices() can unblock such check condition and let other
chipset-specific edac drivers continue with the initialization. @Toshi, What do u think of it?


--
Cheers,
Justin (Jia He)


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.