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

Hi Rafael,

On Fri, 15 May 2026, at 19:10, Rafael J. Wysocki wrote:
> From: "Rafael J. Wysocki" <[email protected]>
>
> 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 <[email protected]>
> Cc: 6.6+ <[email protected]> # 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 :-))

But if the PRM code can deal with EFI_NOT_READY than this is also fine,
modulo the comment below.


> ---
>  drivers/firmware/efi/runtime-wrappers.c |    2 ++
>  1 file changed, 2 insertions(+)
>
> --- a/drivers/firmware/efi/runtime-wrappers.c
> +++ b/drivers/firmware/efi/runtime-wrappers.c
> @@ -590,6 +590,8 @@ efi_call_acpi_prm_handler(efi_status_t (
> 
>  	if (down_interruptible(&efi_runtime_lock))
>  		return EFI_ABORTED;
> +	if (!efi_rts_wq)
> +		return EFI_NOT_READY;

This should occur before taking the semaphore

>  	status = efi_queue_work(ACPI_PRM_HANDLER, handler_addr,
>  				param_buffer_addr, context);
>  	up(&efi_runtime_lock);