> > 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
��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
