Re: [PATCH v3 5/7] efi/runtime-wrappers: bound the wait for EFI runtime service calls
"Ard Biesheuvel" <[email protected]> Sun, 12 Jul 2026 19:25:19 +0300
| Newsgroups | org.kernel.vger.linux-efi,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
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/[email protected]/ [1] Please send patches against efi/next, I will apply them promptly. UpdateCapsule is a special case that we can deal with separately