Hi, Corey.
Osamu Samukawa <osa-samuk...@tg.jp.nec.com> reported a deadlock in the ipmi.
Kosuke Tatsukawa <ta...@ab.jp.nec.com> characterized it as follows.
--------------------------------------------------------------------------------
Below is the source code level stack trace.
ipmi_thread() [drivers/char/ipmi/ipmi_si_intf.c:995]
smi_event_handler() [drivers/char/ipmi/ipmi_si_intf.c:765]
handle_transaction_done() [drivers/char/ipmi/ipmi_si_intf.c:555]
deliver_recv_msg() [drivers/char/ipmi/ipmi_si_intf.c:283]
ipmi_smi_msg_received() [drivers/char/ipmi/ipmi_msghandler.c:4503]
intf_err_seq() [drivers/char/ipmi/ipmi_msghandler.c:1149]
smi_remove_watch() [drivers/char/ipmi/ipmi_msghandler.c:999]
set_need_watch() [drivers/char/ipmi/ipmi_si_intf.c:1066]
Upstream commit e1891cffd4c4896a899337a243273f0e23c028df adds code to
ipmi_smi_msg_received() to call smi_remove_watch() via intf_err_seq()
and this seems to be causing the deadlock.
commit e1891cffd4c4896a899337a243273f0e23c028df
Author: Corey Minyard <cminy...@mvista.com>
Date: Wed Oct 24 15:17:04 2018 -0500
ipmi: Make the smi watcher be disabled immediately when not needed
--------------------------------------------------------------------------------
I looked at the code, and Kosuke's analysis is correct. Function set_need_watch
tries to take out the same si_lock that was taken earlier by ipmi_thread.
Do we really need to take out the si_lock in ipmi_thread? Do we really need to
block IRQs that early?
Thanks and regards,
Tony Camuso
_______________________________________________
Openipmi-developer mailing list
Openipmi-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
