RE: [PATCH V4 0/3] Use efi_rts_wq to invoke EFI Runtime Services

[Prakhya, Sai Praneeth]

> > Changes from V3 to V4:
> > ----------------------
> > 1. As suggested by Peter, use completions instead of flush_work() as the
> >   former is cheaper
> > 2. Call efi_delete_dummy_variable() from efisubsys_init(). Sorry! Ard,
> >   wasn't able to find a better alternative to keep this change local to
> >   arch/x86.
> >
> 
> Two questions:
> - Should the non-blocking variants of the query and set_variable_store use the
> work queue? Doesn't that make them blocking?

That's a good question . I think you are right, calling non-blocking variants of efi_rts 
using work queues makes them blocking. But, I have a follow on question.

Assume some user requested to execute some non-blocking variant of efi_rts and 
the kernel hasn't called efi_call_virt() yet, but was scheduled out. IOW, even though 
user requests for non-blocking efi call, we might still block. Am I right?

With efi_rts_wq, I think, I have increased the window of getting blocked. With efi_rts_wq, 
kernel should explicitly call schedule() to run firmware and the chances of getting blocked 
are much more.

Expect this increased window, I think firmware should be executed as before.

So, can you please explain me the difference between blocking and non-blocking variants
from kernel perspective?
(the way we get locks are different down_interruptible() vs down_trylock())

> - If the non-blocking set_variable() does not use the work queue, can we just call
> it from efi_delete_dummy_variable(), and keep the calls where they are?

Yes, I think we can do that (if we don't use efi_rts_wq for non-blocking variants).

Regards,
Sai