kernel/linux.git/drivers/char/ipmi, branch v5.4.50

ipmi: use vzalloc instead of kmalloc for user creation

2020-06-24T15:50:28+00:00

[ Upstream commit 7c47a219b95d0e06b5ef5fcc7bad807895015eac ] We met mulitple times of failure of staring bmc-watchdog, due to the runtime memory allocation failure of order 4. bmc-watchdog: page allocation failure: order:4, mode:0x40cc0(GFP_KERNEL|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0-1 CPU: 1 PID: 2571 Comm: bmc-watchdog Not tainted 5.5.0-00045-g7d6bb61d6188c #1 Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.00.01.0015.110720180833 11/07/2018 Call Trace: dump_stack+0x66/0x8b warn_alloc+0xfe/0x160 __alloc_pages_slowpath+0xd3e/0xd80 __alloc_pages_nodemask+0x2f0/0x340 kmalloc_order+0x18/0x70 kmalloc_order_trace+0x1d/0xb0 ipmi_create_user+0x55/0x2c0 [ipmi_msghandler] ipmi_open+0x72/0x110 [ipmi_devintf] chrdev_open+0xcb/0x1e0 do_dentry_open+0x1ce/0x380 path_openat+0x305/0x14f0 do_filp_open+0x9b/0x110 do_sys_open+0x1bd/0x250 do_syscall_64+0x5b/0x1f0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Using vzalloc/vfree for creating ipmi_user heals the problem Thanks to Stephen Rothwell for finding the vmalloc.h inclusion issue. Signed-off-by: Feng Tang Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin

ipmi: fix hung processes in __get_guid()

2020-04-17T08:50:22+00:00

commit 32830a0534700f86366f371b150b17f0f0d140d7 upstream. The wait_event() function is used to detect command completion. When send_guid_cmd() returns an error, smi_send() has not been called to send data. Therefore, wait_event() should not be used on the error path, otherwise it will cause the following warning: [ 1361.588808] systemd-udevd D 0 1501 1436 0x00000004 [ 1361.588813] ffff883f4b1298c0 0000000000000000 ffff883f4b188000 ffff887f7e3d9f40 [ 1361.677952] ffff887f64bd4280 ffffc90037297a68 ffffffff8173ca3b ffffc90000000010 [ 1361.767077] 00ffc90037297ad0 ffff887f7e3d9f40 0000000000000286 ffff883f4b188000 [ 1361.856199] Call Trace: [ 1361.885578] [] ? __schedule+0x23b/0x780 [ 1361.951406] [] schedule+0x36/0x80 [ 1362.010979] [] get_guid+0x118/0x150 [ipmi_msghandler] [ 1362.091281] [] ? prepare_to_wait_event+0x100/0x100 [ 1362.168533] [] ipmi_register_smi+0x405/0x940 [ipmi_msghandler] [ 1362.258337] [] try_smi_init+0x529/0x950 [ipmi_si] [ 1362.334521] [] ? std_irq_setup+0xd0/0xd0 [ipmi_si] [ 1362.411701] [] init_ipmi_si+0x492/0x9e0 [ipmi_si] [ 1362.487917] [] ? ipmi_pci_probe+0x280/0x280 [ipmi_si] [ 1362.568219] [] do_one_initcall+0x50/0x180 [ 1362.636109] [] ? kmem_cache_alloc_trace+0x142/0x190 [ 1362.714330] [] do_init_module+0x5f/0x200 [ 1362.781208] [] load_module+0x1898/0x1de0 [ 1362.848069] [] ? __symbol_put+0x60/0x60 [ 1362.913886] [] ? security_kernel_post_read_file+0x6b/0x80 [ 1362.998514] [] SYSC_finit_module+0xe5/0x120 [ 1363.068463] [] ? SYSC_finit_module+0xe5/0x120 [ 1363.140513] [] SyS_finit_module+0xe/0x10 [ 1363.207364] [] do_syscall_64+0x74/0x180 Fixes: 50c812b2b951 ("[PATCH] ipmi: add full sysfs support") Signed-off-by: Wen Yang Cc: Corey Minyard Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: openipmi-developer@lists.sourceforge.net Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # 2.6.17- Message-Id: <20200403090408.58745-1-wenyang@linux.alibaba.com> Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman

ipmi_si: Avoid spurious errors for optional IRQs

2020-03-18T06:17:52+00:00

commit 443d372d6a96cd94ad119e5c14bb4d63a536a7f6 upstream. Although the IRQ assignment in ipmi_si driver is optional, platform_get_irq() spews error messages unnecessarily: ipmi_si dmi-ipmi-si.0: IRQ index 0 not found Fix this by switching to platform_get_irq_optional(). Cc: stable@vger.kernel.org # 5.4.x Cc: John Donnelly Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()") Reported-and-tested-by: Patrick Vo Signed-off-by: Takashi Iwai Message-Id: <20200205093146.1352-1-tiwai@suse.de> Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman

ipmi:ssif: Handle a possible NULL pointer reference

2020-03-05T15:43:35+00:00

[ Upstream commit 6b8526d3abc02c08a2f888e8c20b7ac9e5776dfe ] In error cases a NULL can be passed to memcpy. The length will always be zero, so it doesn't really matter, but go ahead and check for NULL, anyway, to be more precise and avoid static analysis errors. Reported-by: kbuild test robot Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin

drivers: ipmi: fix off-by-one bounds check that leads to a out-of-bounds write

2020-02-19T18:53:05+00:00

commit e0354d147e5889b5faa12e64fa38187aed39aad4 upstream. The end of buffer check is off-by-one since the check is against an index that is pre-incremented before a store to buf[]. Fix this adjusting the bounds check appropriately. Addresses-Coverity: ("Out-of-bounds write") Fixes: 51bd6f291583 ("Add support for IPMB driver") Signed-off-by: Colin Ian King Message-Id: <20200114144031.358003-1-colin.king@canonical.com> Reviewed-by: Asmaa Mnebhi Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman

ipmi: Fix memory leak in __ipmi_bmc_register

2020-01-26T09:01:02+00:00

commit 4aa7afb0ee20a97fbf0c5bab3df028d5fb85fdab upstream. In the impelementation of __ipmi_bmc_register() the allocated memory for bmc should be released in case ida_simple_get() fails. Fixes: 68e7e50f195f ("ipmi: Don't use BMC product/dev ids in the BMC name") Signed-off-by: Navid Emamdoost Message-Id: <20191021200649.1511-1-navid.emamdoost@gmail.com> Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman

ipmi: Don't allow device module unload when in use

2019-12-31T15:44:14+00:00

[ Upstream commit cbb79863fc3175ed5ac506465948b02a893a8235 ] If something has the IPMI driver open, don't allow the device module to be unloaded. Before it would unload and the user would get errors on use. This change is made on user request, and it makes it consistent with the I2C driver, which has the same behavior. It does change things a little bit with respect to kernel users. If the ACPI or IPMI watchdog (or any other kernel user) has created a user, then the device module cannot be unloaded. Before it could be unloaded, This does not affect hot-plug. If the device goes away (it's on something removable that is removed or is hot-removed via sysfs) then it still behaves as it did before. Reported-by: tony camuso Signed-off-by: Corey Minyard Tested-by: tony camuso Signed-off-by: Sasha Levin

ipmi_si_intf: Fix race in timer shutdown handling

2019-09-12T21:03:18+00:00

smi_mod_timer() enables the timer before setting timer_running. This means the timer can be running when we get to stop_timer_and_thread() without timer_running having been set, resulting in del_timer_sync() not being called and the timer being left to cause havoc during shutdown. Instead just call del_timer_sync() unconditionally Signed-off-by: Jes Sorensen Message-Id: <20190828203625.32093-2-Jes.Sorensen@gmail.com> Signed-off-by: Corey Minyard

ipmi: move message error checking to avoid deadlock

2019-08-22T16:08:13+00:00

V1->V2: in handle_one_rcv_msg, if data_size > 2, set requeue to zero and goto out instead of calling ipmi_free_msg. Kosuke Tatsukawa In the source stack trace below, function set_need_watch tries to take out the same si_lock that was taken earlier by ipmi_thread. 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 Date: Wed Oct 24 15:17:04 2018 -0500 ipmi: Make the smi watcher be disabled immediately when not needed The fix is to put all messages in the queue and move the message checking code out of ipmi_smi_msg_received and into handle_one_recv_msg, which processes the message checking after ipmi_thread releases its locks. Additionally,Kosuke Tatsukawa reported that handle_new_recv_msgs calls ipmi_free_msg when handle_one_rcv_msg returns zero, so that the call to ipmi_free_msg in handle_one_rcv_msg introduced another panic when "ipmitool sensor list" was run in a loop. He submitted this part of the patch. +free_msg: + requeue = 0; + goto out; Reported by: Osamu Samukawa Characterized by: Kosuke Tatsukawa Signed-off-by: Tony Camuso Fixes: e1891cffd4c4 ("ipmi: Make the smi watcher be disabled immediately when not needed") Cc: stable@vger.kernel.org # 5.1 Signed-off-by: Corey Minyard

ipmi_ssif: avoid registering duplicate ssif interface

2019-08-22T16:06:33+00:00

It is possible that SSIF interface entry is present in both DMI and ACPI tables. In SMP systems, in such cases it is possible that ssif_probe could be called simultaneously from i2c interface (from ACPI) and from DMI on different CPUs at kernel boot. Both try to register same SSIF interface simultaneously and result in race. In such cases where ACPI and SMBIOS both IPMI entries are available, we need to prefer ACPI over SMBIOS so that ACPI functions work properly if they use IPMI. So, if we get an ACPI interface and have already registered an SMBIOS at the same address, we need to remove the SMBIOS one and add the ACPI. Log: [ 38.774743] ipmi device interface [ 38.805006] ipmi_ssif: IPMI SSIF Interface driver [ 38.861979] ipmi_ssif i2c-IPI0001:06: ssif_probe CPU 99 *** [ 38.863655] ipmi_ssif 0-000e: ssif_probe CPU 14 *** [ 38.863658] ipmi_ssif: Trying SMBIOS-specified SSIF interface at i2c address 0xe, adapter xlp9xx-i2c, slave address 0x0 [ 38.869500] ipmi_ssif: Trying ACPI-specified SSIF interface at i2c address 0xe, adapter xlp9xx-i2c, slave address 0x0 [ 38.914530] ipmi_ssif: Unable to clear message flags: -22 7 c7 [ 38.952429] ipmi_ssif: Unable to clear message flags: -22 7 00 [ 38.994734] ipmi_ssif: Error getting global enables: -22 7 00 [ 39.015877] ipmi_ssif 0-000e: IPMI message handler: Found new BMC (man_id: 0x00b3d1, prod_id: 0x0001, dev_id: 0x20) [ 39.377645] ipmi_ssif i2c-IPI0001:06: IPMI message handler: Found new BMC (man_id: 0x00b3d1, prod_id: 0x0001, dev_id: 0x20) [ 39.387863] ipmi_ssif 0-000e: IPMI message handler: BMC returned incorrect response, expected netfn 7 cmd 42, got netfn 7 cmd 1 ... [NOTE] : Added custom prints to explain the problem. In the above log, ssif_probe is executed simultaneously on two different CPUs. This patch fixes this issue in following way: - Adds ACPI entry also to the 'ssif_infos' list. - Checks the list if SMBIOS is already registered, removes it and adds ACPI. - If ACPI is already registered, it ignores SMBIOS. - Adds mutex lock throughout the probe process to avoid race. Signed-off-by: Kamlakant Patel Message-Id: <1566389064-27356-1-git-send-email-kamlakantp@marvell.com> Signed-off-by: Corey Minyard