Re: [PATCH v1] efi/runtime-wrappers: Avoid crashing on early PRM code invocations

[Ard Biesheuvel]

On Mon, 18 May 2026, at 21:29, Rafael J. Wysocki wrote:
> On Friday, May 15, 2026 7:29:03 PM CEST Ard Biesheuvel wrote:
>> Hi Rafael,
>> 
>> On Fri, 15 May 2026, at 19:10, Rafael J. Wysocki wrote:
>> > From: "Rafael J. Wysocki" <rafael.j.wysocki@xxxxxxxxx>
>> >
>> > There is a dependency between EFI and ACPI PRM that the latter cannot
>> > run until the former is ready and PRM can be invoked from AML early
>> > through acpi_platformrt_space_handler().  If that happens before
>> > initializing efi_rts_wq, it leads to a NULL pointer dereference.
>> >
>> > Avoid that by adding an efi_rts_wq check against NULL to
>> > efi_call_acpi_prm_handler().
>> >
>> > Fixes: 5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM 
>> > handlers")
>> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
>> > Cc: 6.6+ <stable@xxxxxxxxxxxxxxx> # 6.6+
>> > ---
>> >
>> > An alternative would be to somehow ensure that efisubsys_init() will always
>> > run before acpi_init(), but moving any of them to another initcall level is
>> > not an option AFAICS.
>> >
>> 
>> Given that they both run as subsys_initcall() currently, changing acpi_init()
>> to subsys_initcall_sync() is probably fine (famous last words :-))
>
> Well, not quite because there is stuff depending on ACPI in that initcall level
> (MWI and CXL, probably among other things).
>

Oh right.

>> But if the PRM code can deal with EFI_NOT_READY than this is also fine,
>> modulo the comment below.
>
> It can, but that is not ideal because if EFI_NOT_READY is returned, so AML will
> be aborted and that may be something like a GPE handler method, so it would be
> better to ensure the working order.
>
> Something like the patch below can be done.  It works AFAICS, but the initcall
> error handling is a bit awkward (it is for debug though, so not a big deal I
> guess).  If this is acceptable, I can send it as a v2.
>

I'd rather fix this more comprehensively if we can, by either
- moving the workqueue allocation into a separate initcall that executes
before subsys, or
- omitting the workqueue for early calls, and dispatching the PRM calls
directly from the calling thread, similar to how ResetSystem() is routed.

As far as I can tell, option #1 (which I prefer) is feasible because the
actual setup of the EFI runtime environment occurs way earlier, and only
the allocation of the workqueue is missing. Could you please verify if
that would fix this?