linux/drivers/char/ipmi, branch v4.7

ipmi: Remove smi_msg from waiting_rcv_msgs list before handle_one_recv_msg()

2016-06-13T13:56:28Z

Commit 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for SMI interfaces") changed handle_new_recv_msgs() to call handle_one_recv_msg() for a smi_msg while the smi_msg is still connected to waiting_rcv_msgs list. That could lead to following list corruption problems: 1) low-level function treats smi_msg as not connected to list handle_one_recv_msg() could end up calling smi_send(), which assumes the msg is not connected to list. For example, the following sequence could corrupt list by doing list_add_tail() for the entry still connected to other list. handle_new_recv_msgs() msg = list_entry(waiting_rcv_msgs) handle_one_recv_msg(msg) handle_ipmb_get_msg_cmd(msg) smi_send(msg) spin_lock(xmit_msgs_lock) list_add_tail(msg) spin_unlock(xmit_msgs_lock) 2) race between multiple handle_new_recv_msgs() instances handle_new_recv_msgs() once releases waiting_rcv_msgs_lock before calling handle_one_recv_msg() then retakes the lock and list_del() it. If others call handle_new_recv_msgs() during the window shown below list_del() will be done twice for the same smi_msg. handle_new_recv_msgs() spin_lock(waiting_rcv_msgs_lock) msg = list_entry(waiting_rcv_msgs) spin_unlock(waiting_rcv_msgs_lock) | | handle_one_recv_msg(msg) | spin_lock(waiting_rcv_msgs_lock) list_del(msg) spin_unlock(waiting_rcv_msgs_lock) Fixes: 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for SMI interfaces") Signed-off-by: Jun'ichi Nomura [Added a comment to describe why this works.] Signed-off-by: Corey Minyard Cc: stable@vger.kernel.org # 3.19 Tested-by: Ye Feng

ipmi: Fix the I2C address extraction from SPMI tables

2016-05-17T00:49:49Z

Unlike everywhere else in the IPMI specification, the I2C address specified in the SPMI table is not shifted to the left one bit with the LSB zero. Instead it is not shifted with the MSB zero. Reported-by: Sanjeev Signed-off-by: Corey Minyard

IPMI: reserve memio regions separately

2016-05-17T00:49:48Z

Commit d61a3ead2680 ("[PATCH] IPMI: reserve I/O ports separately") changed the way I/O ports were reserved and includes this comment in log: Some BIOSes reserve disjoint I/O regions in their ACPI tables for the IPMI controller. This causes problems when trying to register the entire I/O region. Therefore we must register each I/O port separately. There is a similar problem with memio regions on an arm64 platform (AMD Seattle). Where I see: ipmi message handler version 39.2 ipmi_si AMDI0300:00: probing via device tree ipmi_si AMDI0300:00: ipmi_si: probing via ACPI ipmi_si AMDI0300:00: [mem 0xe0010000] regsize 1 spacing 4 irq 23 ipmi_si: Adding ACPI-specified kcs state machine IPMI System Interface driver. ipmi_si: Trying ACPI-specified kcs state machine at mem \ address 0xe0010000, slave address 0x0, irq 23 ipmi_si: Could not set up I/O space The problem is that the ACPI core registers disjoint regions for the platform device: e0010000-e0010000 : AMDI0300:00 e0010004-e0010004 : AMDI0300:00 and the ipmi_si driver tries to register one region e0010000-e0010004. Based on a patch from Mark Salter , who also wrote all the above text. Signed-off-by: Corey Minyard Tested-by: Mark Salter

ipmi: Fix some minor coding style issues

2016-05-17T00:49:48Z

Signed-off-by: Corey Minyard

ipmi/watchdog: use nmi_panic() when kernel panics in NMI handler

2016-03-22T22:36:02Z

Commit 1717f2096b54 ("panic, x86: Fix re-entrance problem due to panic on NMI") introduced nmi_panic() which prevents concurrent and recursive execution of panic(). It also saves registers for the crash dump on x86 by later commit 58c5661f2144 ("panic, x86: Allow CPUs to save registers even if looping in NMI context"). ipmi_watchdog driver can call panic() from NMI handler, so replace it with nmi_panic(). Signed-off-by: Hidehiro Kawai Acked-by: Corey Minyard Acked-by: Guenter Roeck Reviewed-by: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

ipmi: do not probe ACPI devices if si_tryacpi is unset

2016-03-18T12:01:24Z

Extend the tryacpi module parameter to turn off acpi_ipmi_probe such that hard-coded options (type, ports, address, etc.) have complete control over the smi_info data structures setup by the driver. Signed-off-by: Joe Lawrence Signed-off-by: Corey Minyard

ipmi_si: Avoid a wrong long timeout on transaction done

2016-03-18T12:01:23Z

Under some circumstances, the IPMI state machine could return a call without delay option but the driver would still do a long delay because the result wasn't checked. Instead of calling the state machine after transaction done, just go back to the top of the processing to start over. Signed-off-by: Corey Minyard

ipmi_si: Fix module parameter doc names

2016-03-18T12:01:23Z

Several were tryacpi instead of their actual values. Signed-off-by: Corey Minyard

ipmi_ssif: Fix logic around alert handling

2016-03-18T12:01:23Z

There was a mistake in the logic, if an alert came in very quickly it would hang the driver. Signed-off-by: Corey Minyard

ipmi: put acpi.h with the other headers

2016-02-03T16:35:52Z

Enclosing '#include ' within '#ifdef CONFIG_ACPI' is unnecessary, since it has its own conditional compile for CONFIG_ACPI. Commit 0fbcf4af7c83 ("ipmi: Convert the IPMI SI ACPI handling to a platform device") exposed this as a problem for platforms that do not support ACPI when it introduced a call to ACPI_PTR() macro outside of the CONFIG_ACPI conditional compile. This would have been perfectly acceptable if acpi.h were not conditionally excluded for the non-acpi platform, because the conditional compile within acpi.h defines ACPI_PTR() to return NULL when compiled for non acpi platforms. Signed-off-by: Tony Camuso Fixed commit reference in header to conform to standard. Signed-off-by: Corey Minyard