Re: [PATCH v3 5/7] efi/runtime-wrappers: bound the wait for EFI runtime service calls

[Ard Biesheuvel]

On Fri, 10 Jul 2026, at 16:47, Breno Leitao wrote:
> On Fri, Jul 10, 2026 at 12:26:42PM +0100, Yeoreum Yun wrote:
>> > On Fri, Jul 10, 2026 at 11:41:09AM +0100, Yeoreum Yun wrote:
>> > > > Hello Yeoreum,
>> > > > 
>> > > > On Thu, Jul 09, 2026 at 07:56:18AM +0100, Yeoreum Yun wrote:
>> > > > > 
>> > > > > One of my concern is for the UpdateCapsule runtime service.
>> > > > > It might have a case where takes more then 2 mins and there's one
>> > > > > RFC to support a runtime capsule update for arm platform [1].
>> > > > 
>> > > > I'm not familiar with UpdateCapsule. Are you suggesting that a 2-minute
>> > > > wait for an EFI call should be acceptable (?!)
>> > > > 
>> > > > Wouldn't that trigger stalls and hung-task/wq warnings throughout the
>> > > > kernel?
>> > > 
>> > > Might for default config timeout for hung-task. However at least
>> > > its timeout configurable.
>> > > 
>> > > TBH, normally it wouldn't task more than 2 mins.
>> > > But for a in case of *slow firmware*, would be good to make
>> > > runtime-service timeout configurable at least?
>> > 
>> > OK, that is fair request.
>> > 
>> > I would suggest we do an additional patch with this change, if Ard is
>> > positive on the idea.
>> > 
>> > Yeoreum, would you like to do it, or should I do it?
>> 
>> It's up to you. I don't care who will do this :)
>> But if you have no bandwidth, I'll take once your patch is merged
>> and Ard agrees for this.
>
> Sounds good. Let's wait for Ard's feedback on the additional patches
> [1], and we can decide how to proceed from there.
>
> Link: https://lore.kernel.org/all/alDDv3XGXVdd1mri@xxxxxxxxx/ [1]

Please send patches against efi/next, I will apply them promptly. 

UpdateCapsule is a special case that we can deal with separately