On Mon, 21 Mar, at 08:31:59PM, Matt Fleming wrote: > > Good question. They're not handled in any special way with this patch > series, so the firmware will just initiate its own reset inside of > UpdateCapsule(). > > That's probably not what we want, because things like on-disk > consistency are not guaranteed if the machine spontaneously reboots > without assistance from the kernel. > > The simplest thing to do is to refuse to pass such capsules to the > firmware, since it's likely not going to be a common use case. But > maybe that's overly restrictive. > > Let me have a think about that one. OK, I did think about this, and until someone actually requests the ability to handle CAPSULE_FLAGS_INITIATE_RESET, I'm happy to just punt on the problem. Anyone got any objections? --- diff --git a/drivers/firmware/efi/capsule.c b/drivers/firmware/efi/capsule.c index dac25208ad5e..84450e9cdf41 100644 --- a/drivers/firmware/efi/capsule.c +++ b/drivers/firmware/efi/capsule.c @@ -84,6 +84,14 @@ int efi_capsule_supported(efi_guid_t guid, u32 flags, size_t size, int *reset) u64 max_size; int rv = 0; + /* + * We do not handle firmware-initiated reset because that + * would require us to prepare the kernel for reboot. Refuse + * to load any capsules with that flag. + */ + if (flags & EFI_CAPSULE_INITIATE_RESET) + return -EINVAL; + capsule = kmalloc(sizeof(*capsule), GFP_KERNEL); if (!capsule) return -ENOMEM; -- 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
