Re: [PATCH] firmware: efi: add a separate timeout for UpdateCapsule()

["Ard Biesheuvel" <ardb@kernel.org>]

On Thu, 3 Sep 2026, at 16:29, Ard Biesheuvel wrote:
> On Thu, 3 Sep 2026, at 16:10, Yeoreum Yun wrote:
>> Hi Ard,
>>
>>> Hello Yeoreum Yun,
>>> 
>>> On Thu, 3 Sep 2026, at 13:32, Yeoreum Yun wrote:
>>> > On platforms that allows to update firmware in runtime, UpdateCapsule()
>>> > may immediately write a firmware image to persistent storage.
>>> > This operation can take longer than EFI_RTS_TIMEOUT.
>>> >
>>> > Use a separate timeout for the UpdateCapsule() runtime service. By
>>> > default, wait indefinitely to avoid interrupting an ongoing firmware
>>> > update. Administrators may configure an appropriate timeout, in seconds,
>>> > through /sys/firmware/efi/capsule_update_timeout.
>>> >
>>> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
>>> > ---
>>> >  drivers/firmware/efi/efi.c              | 41 +++++++++++++++++++++++++
>>> >  drivers/firmware/efi/runtime-wrappers.c | 14 +++------
>>> >  include/linux/efi.h                     | 10 ++++++
>>> >  3 files changed, 55 insertions(+), 10 deletions(-)
>>> >
>>> 
>>> Given that UpdateCapsule() is rarely used these days at runtime, I
>>> wonder if we should just call it synchronously instead of via the
>>> EFI workqueue.
>>> 
>>> I assume that would also solve the timeout issue?
>>
>> Might be. But it would make *non-preemptible* for UpdateCapsule().
>> AFAIK the purpose of running runtime service with efi_queue to
>> run it in indepdent context and to be preemtible in case of arm64.
>>
>
> No.
>
>> Since most of UpdateCapsule() will be called via capsule-loader's misc
>> device, if UpdateCaspule() is called synchronously, It would be
>> non-preemtible in arm64 platform.
>>
>> But, some platform could be preemptible while updating firmware so
>> I think it would be better that it would be called via EFI workqueue.
>>
>
> EFI runtime service invocations are preemptible on arm64, so this is
> not a problem.

Ah wait - you're right, they are only preemptible when invoked from the
work queue.