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