summaryrefslogtreecommitdiff
path: root/drivers/char
diff options
context:
space:
mode:
authorHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>2015-07-27 14:55:16 +0900
committerCorey Minyard <cminyard@mvista.com>2015-09-03 15:02:29 -0500
commitc49c097610fe1aabf86111297280a718abb5dcc2 (patch)
treeeb77edc3a4b9f00decae0fb97a591546bbf07bea /drivers/char
parent06e5e345fea8df24b1d935f98741343df4cab664 (diff)
ipmi: Don't call receive handler in the panic context
Received handlers defined as ipmi_recv_hndl member of struct ipmi_user_hndl can take a spinlock. This means that if the kernel panics while holding the lock, a deadlock may happen on the lock while flushing queued messages in the panic context. Calling the receive handler doesn't make much meanings in the panic context, simply skip it to avoid possible deadlocks. Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
Diffstat (limited to 'drivers/char')
-rw-r--r--drivers/char/ipmi/ipmi_msghandler.c8
1 files changed, 7 insertions, 1 deletions
diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c
index cdac5f7037e5..e3536da05c88 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -744,7 +744,13 @@ static void deliver_response(struct ipmi_recv_msg *msg)
ipmi_inc_stat(intf, unhandled_local_responses);
}
ipmi_free_recv_msg(msg);
- } else {
+ } else if (!oops_in_progress) {
+ /*
+ * If we are running in the panic context, calling the
+ * receive handler doesn't much meaning and has a deadlock
+ * risk. At this moment, simply skip it in that case.
+ */
+
ipmi_user_t user = msg->user;
user->handler->ipmi_recv_hndl(msg, user->handler_data);
}