kernel/drivers/char/ipmi, branch linux-4.3.y

ipmi: move timer init to before irq is setup

2016-01-31T19:25:44Z

commit 27f972d3e00b50639deb4cc1392afaeb08d3cecc upstream. We encountered a panic on boot in ipmi_si on a dell per320 due to an uninitialized timer as follows. static int smi_start_processing(void *send_info, ipmi_smi_t intf) { /* Try to claim any interrupts. */ if (new_smi->irq_setup) new_smi->irq_setup(new_smi); --> IRQ arrives here and irq handler tries to modify uninitialized timer which triggers BUG_ON(!timer->function) in __mod_timer(). Call Trace: [] start_new_msg+0x47/0x80 [ipmi_si] [] start_check_enables+0x4e/0x60 [ipmi_si] [] smi_event_handler+0x1e8/0x640 [ipmi_si] [] ? __rcu_process_callbacks+0x54/0x350 [] si_irq_handler+0x3c/0x60 [ipmi_si] [] handle_IRQ_event+0x60/0x170 [] handle_edge_irq+0xde/0x180 [] handle_irq+0x49/0xa0 [] do_IRQ+0x6c/0xf0 [] ret_from_intr+0x0/0x11 /* Set up the timer that drives the interface. */ setup_timer(&new_smi->si_timer, smi_timeout, (long)new_smi); The following patch fixes the problem. To: Openipmi-developer@lists.sourceforge.net To: Corey Minyard CC: linux-kernel@vger.kernel.org Signed-off-by: Jan Stancek Signed-off-by: Tony Camuso Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman

ipmi: Start the timer and thread on internal msgs

2016-01-31T19:25:44Z

commit 0cfec916e86d881e209de4b4ae9959a6271e6660 upstream. The timer and thread were not being started for internal messages, so in interrupt mode if something hung the timer would never go off and clean things up. Factor out the internal message sending and start the timer for those messages, too. Signed-off-by: Corey Minyard Tested-by: Gouji, Masayuki Signed-off-by: Greg Kroah-Hartman

ipmi:ssif: Add a module parm to specify that SMBus alerts don't work

2015-09-03T20:02:31Z

They are broken on some platforms, this gives people a chance to work around it until the firmware is fixed. Signed-off-by: Corey Minyard

ipmi: add of_device_id in MODULE_DEVICE_TABLE

2015-09-03T20:02:31Z

Fix autoloading ipmi modules when using device tree. Signed-off-by: Brijesh Singh Moved this change up into the CONFIG_OF section to account for changes to the probing code. Signed-off-by: Corey Minyard

ipmi: Compensate for BMCs that wont set the irq enable bit

2015-09-03T20:02:30Z

It appears that some BMCs support interrupts but don't support setting the irq enable bits. The interrupts are just always on. Sigh. Add code to compensate. The new code was very similar to another functions, so this also factors out the common code into other functions. Signed-off-by: Corey Minyard Tested-by: Henrik Korkuc

ipmi: Don't call receive handler in the panic context

2015-09-03T20:02:29Z

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 Signed-off-by: Corey Minyard

ipmi: Avoid touching possible corrupted lists in the panic context

2015-09-03T20:02:29Z

When processing queued messages in the panic context, IPMI driver tries to do it without any locking to avoid deadlocks. However, this means we can touch a corrupted list if the kernel panicked while manipulating the list. Fortunately, current `add-tail and del-from-head' style implementation won't touch the corrupted part, but it is inherently risky. To get rid of the risk, this patch re-initializes the message lists on panic if the related spinlock has already been acquired. As the result, we may lose queued messages, but it's not so painful. Dropping messages on the received message list is also less problematic because no one can respond the received messages. Signed-off-by: Hidehiro Kawai Fixed a comment typo. Signed-off-by: Corey Minyard

ipmi: Don't flush messages in sender() in run-to-completion mode

2015-09-03T20:02:28Z

When flushing queued messages in run-to-completion mode, smi_event_handler() is recursively called. flush_messages() smi_event_handler() handle_transaction_done() deliver_recv_msg() ipmi_smi_msg_received() smi_recv_tasklet() sender() flush_messages() smi_event_handler() ... The depth of the recursive call depends on the number of queued messages, so it can cause a stack overflow if many messages have been queued. To solve this problem, this patch removes flush_messages() from sender()@ipmi_si_intf.c. Instead, add flush_messages() to caller side of sender() if needed. Additionally, to implement this, add new handler flush_messages to struct ipmi_smi_handlers. Signed-off-by: Hidehiro Kawai Fixed up a comment and some spacing issues. Signed-off-by: Corey Minyard

ipmi: Factor out message flushing procedure

2015-09-03T20:02:28Z

Factor out message flushing procedure which is used in run-to-completion mode. This patch doesn't change the logic. Signed-off-by: Hidehiro Kawai Signed-off-by: Corey Minyard

ipmi: Remove unneeded set_run_to_completion call

2015-09-03T20:02:27Z

send_panic_events() calls intf->handlers->set_run_to_completion(), but it has already been done in the caller function panic_event(). Remove it from send_panic_events(). Signed-off-by: Hidehiro Kawai Signed-off-by: Corey Minyard