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

[Prakhya, Sai Praneeth]

> > One more question again, if we are sure that non-blocking variants
> > will _always_ be called in atomic context, then, we got it covered.
> > Because, in
> > set_variable() and query_variable_info() (both blocking and
> > non-blocking) we check for in_atomic() and if so, we don't use efi_rts_wq
> (please refer to patch 3).
> >
> > If you think, there might be a probability of calling non-blocking
> > efi_rts out of atomic context, then, sure! Let's make them never use
> efi_rts_wq.
> >
> 
> This is not about what happens to be the current situation. It is about the API.
> 
> The non-blocking functions should never block, period. They either fail gracefully
> or perform their duties without sleeping.

Yes, that makes sense.

> 
> In this particular case, I think it is useful to have a guaranteed non-blocking
> version, not only to delete the dummy EFI variable, but potentially in other
> future cases as well, given that they can be called much earlier in the boot (when
> the perf/%cr3 issue is not a concern to begin with)

Thanks for making it more clear :)
I will change the non-blocking variants _not_ to use efi_rts_wq and as you suggested 
make efi_delete_dummy_variable() use non-blocking variants (that should also make it 
local to arch/x86).

Another follow on question is, does every firmware support both blocking and 
non-blocking variants (specially legacy EFI firmware)? I am worried about 
this because, presently efi_delete_dummy_variable() uses set_variable() and 
query_variable_info() but if I change efi_delete_dummy_variable() to use non-blocking 
variants and if they arenât supported, then, I guess, efi_delete_dummy_variable() might 
fail :(

So, could you please clarify on that?

Regards,
Sai