diff options
author | Matt Fleming <matt.fleming@intel.com> | 2014-09-30 14:03:38 (GMT) |
---|---|---|
committer | Matt Fleming <matt.fleming@intel.com> | 2014-10-03 17:41:03 (GMT) |
commit | 60b4dc7720a5251f5dbda69ad404e0bcb3cb6bfb (patch) | |
tree | fca7b787763f26f7e197fab447d00943fcd13439 /drivers/rtc | |
parent | 6d80dba1c9fe4316ef626980102b92fa30c7845a (diff) | |
download | linux-60b4dc7720a5251f5dbda69ad404e0bcb3cb6bfb.tar.xz |
efi: Delete the in_nmi() conditional runtime locking
commit 5dc3826d9f08 ("efi: Implement mandatory locking for UEFI Runtime
Services") implemented some conditional locking when accessing variable
runtime services that Ingo described as "pretty disgusting".
The intention with the !efi_in_nmi() checks was to avoid live-locks when
trying to write pstore crash data into an EFI variable. Such lockless
accesses are allowed according to the UEFI specification when we're in a
"non-recoverable" state, but whether or not things are implemented
correctly in actual firmware implementations remains an unanswered
question, and so it would seem sensible to avoid doing any kind of
unsynchronized variable accesses.
Furthermore, the efi_in_nmi() tests are inadequate because they don't
account for the case where we call EFI variable services from panic or
oops callbacks and aren't executing in NMI context. In other words,
live-locking is still possible.
Let's just remove the conditional locking altogether. Now we've got the
->set_variable_nonblocking() EFI variable operation we can abort if the
runtime lock is already held. Aborting is by far the safest option.
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Diffstat (limited to 'drivers/rtc')
0 files changed, 0 insertions, 0 deletions