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

[Ard Biesheuvel]

On 27 May 2018 at 10:37, Prakhya, Sai Praneeth
<sai.praneeth.prakhya@xxxxxxxxx> wrote:
>> > 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).
>

Yes, please.

> 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?
>

I don't follow. Why should it make any difference to the firmware
whether the OS routines blocks or gives up? We always honor the mutual
exclusion between different invocations of runtime services, and the
firmware itself has no awareness of the kind of scheduling the OS
needs to do to ensure this.