[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3a9eb8eb-3420-4232-8259-3b33ed45dc66@siemens.com>
Date: Thu, 21 Aug 2025 15:00:13 +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 16:59, Jan Kiszka wrote:
> 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.
>
If there are no concerns, I will switch to EFI_DEVICE_ERROR and even
drop the error "ret" argument in v2.
Jan
--
Siemens AG, Foundational Technologies
Linux Expert Center
Powered by blists - more mailing lists