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

[Yeoreum Yun <yeoreum.yun@arm.com>]

Hi Ard,

> 
> On Tue, 15 Sep 2026, at 10:49, Yeoreum Yun wrote:
> >> > 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.
> >> 
> >> Yes. That's why I think it would be better to call via EFI workqueue
> >> when I see arch_efi_call_virt_setup().
> >
> > Hi Ard,
> >
> > Could there be any issues with doing it this way, or would there be
> > a better approach?
> >
> 
> Would it make sense to simply have different limits for UpdateCapsule() and
> for everything else? How much longer than 2 minutes do you need in the
> typical case?

Although the time required to complete a firmware update depends onthe platform
and other factors, such as whether the capsule contains a single firmware image
or multiple images, it is generally reasonable to expect the update to complete
within 10 minutes.

If, for some reason, an update is expected to take longer than 10 minutes,
the sysfs interface for configuring capsule_update_timeout would be useful.

This would allow the timeout to be adjusted as needed, for example to
15 minutes, before capsule update. 

Am I missing something?

-- 
Sincerely,
Yeoreum Yun