[Issue]
There is a scenario which efi_pstore may hang up:
- cpuA grabs efivars->lock
- cpuB panics and calls smp_send_stop
- smp_send_stop sends IRQ to cpuA
- after 1 second, cpuB gives up on cpuA and sends an NMI instead
- cpuA is now in an NMI handler while still holding efivars->lock
- cpuB is deadlocked
This case may happen if a firmware has a bug and
cpuA is stuck talking with it.
[Solution]
This patch changes a spin_lock to a spin_trylock in non-blocking paths.
and if the spin_lock has already taken by another cpu,
it returns without accessing to a firmware to avoid the deadlock.
Signed-off-by: Seiji Aguchi <seiji.agu...@hds.com>
Acked-by: Don Zickus <dzic...@redhat.com>
Acked-by: Tony Luck <tony.l...@intel.com>
---
drivers/firmware/efivars.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index 7b1c374..ef5070d 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -1209,7 +1209,16 @@ static int efi_pstore_write(enum pstore_type_id type,
u64 storage_space, remaining_space, max_variable_size;
efi_status_t status = EFI_NOT_FOUND;
- spin_lock(&efivars->lock);
+ if (pstore_cannot_block_path(reason)) {
+ /*
+ * If the lock is taken by another cpu in non-blocking path,
+ * this driver returns without entering firmware to avoid
+ * hanging up.
+ */
+ if (!spin_trylock(&efivars->lock))
+ return -EBUSY;
+ } else
+ spin_lock(&efivars->lock);
/*
* Check if there is a space enough to log.
-- 1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
