On Thu, 26 Sep 2019 at 17:47, Ross Lagerwall <ross.lagerwall@xxxxxxxxxx> wrote: > > On 9/26/19 4:29 PM, Ard Biesheuvel wrote: > > On Thu, 26 Sep 2019 at 16:12, Ross Lagerwall <ross.lagerwall@xxxxxxxxxx> wrote: > >> > >> If a backend does not implement non-blocking EFI operations, it implies > >> that the normal operations are non-blocking. > > > > Is that documented anywhere? > > Sort of. From commit 6d80dba1c9fe "efi: Provide a non-blocking > SetVariable() operation" > > """ > Introduce ->set_variable_nonblocking() for this use case. It is an > optional EFI backend operation, and need only be implemented by those > backends that usually acquire locks to serialize access to EFI > variables, as is the case for virt_efi_set_variable() where we now grab > the EFI runtime spinlock. > """ > > > > >> Instead of crashing > >> dereferencing a NULL pointer, fallback to the normal operations since it > >> is safe to do so. > >> > > > > I agree that crashing is never the right thing to do, but I wonder > > whether we shouldn't just bail instead. If the provided default > > operation is non-blocking, the platform can populate the function > > pointer with a reference to the default implementation. > > If you would prefer it that platforms are always required to implement > the non-blocking functions, then I will just send a simple patch fixing > up the Xen implementation. > Yes, please, that sounds like a safer option to me.
