[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50f7f2fc-2c6d-4ae1-bbce-e132b1d9c9fe@siemens.com>
Date: Wed, 20 Aug 2025 16:59:03 +0200
From: Jan Kiszka <jan.kiszka@...mens.com>
To: Ilias Apalodimas <ilias.apalodimas@...aro.org>
Cc: Ard Biesheuvel <ardb@...nel.org>,
Masahisa Kojima <masahisa.kojima@...aro.org>, linux-efi@...r.kernel.org,
linux-kernel@...r.kernel.org, Sumit Garg <sumit.garg@...aro.org>,
Jens Wiklander <jens.wiklander@...aro.org>
Subject: Re: [PATCH 2/3] efi: stmm: Use EFI return code of setup_mm_hdr
On 20.08.25 09:10, Ilias Apalodimas wrote:
> Hi Jan
>
> On Fri, 15 Aug 2025 at 22:12, Jan Kiszka <jan.kiszka@...mens.com> wrote:
>>
>> From: Jan Kiszka <jan.kiszka@...mens.com>
>>
>> If a too large payload_size is passed to setup_mm_hdr, callers will
>> returned EFI_OUT_OF_RESOURCES rather than EFI_INVALID_PARAMETER that is
>> passed down via ret. No need to fold errors here.
>
> Apart from not folding the error here, the current code kind of
> violates the EFI spec.
> If you look at GetVariable, GetNextVariable, SetVariable, and
> QueryVariableInfo only SetVariable is supposed to return
> EFI_OUT_OF_RESOURCES, if there's no storage space left.
And with storage space is likely meant the persistent part of it. ENOMEM
is something different.
>
> Should we also change setup_mm_hdr() and return EFI_INVALID_PARAMETER
> always? It's still not ideal, but much closer to the spec.
EFI_DEVICE_ERROR? The "hardware" is has a problem by not providing us
enough RAM. Yeah, not optimal either. But invalid parameter is clearly
described, and nothing fits.
Jan
--
Siemens AG, Foundational Technologies
Linux Expert Center
Powered by blists - more mailing lists