On 27 May 2018 at 07:32, Prakhya, Sai Praneeth <sai.praneeth.prakhya@xxxxxxxxx> wrote: >> > 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. > 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. 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) -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
