> > 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?
> >
>
> No, that is the whole point. These functions may be called from atomic context,
> which is why they trylock() and give up rather than block on the semaphore if a rt
> services call is already in progress. E.g.,
>
> /*
> * efivar_entry_set_nonblocking - call set_variable_nonblocking()
> *
> * This function is guaranteed to not block and is suitable for calling
> * from crash/panic handlers.
> *
> * Crucially, this function will not block if it cannot acquire
> * efivars_lock. Instead, it returns -EBUSY.
> */
>
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.
Regards,
Sai
��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
