linux-stable.git/drivers/char/ipmi, branch v5.4.166

ipmi: msghandler: Make symbol 'remove_work_wq' static

2021-12-08T08:01:15+00:00

commit 5a3ba99b62d8486de0316334e72ac620d4b94fdd upstream.

The sparse tool complains as follows:

drivers/char/ipmi/ipmi_msghandler.c:194:25: warning:
 symbol 'remove_work_wq' was not declared. Should it be static?

This symbol is not used outside of ipmi_msghandler.c, so
marks it static.

Fixes: 1d49eb91e86e ("ipmi: Move remove_work to dedicated workqueue")
Reported-by: Hulk Robot 
Signed-off-by: Wei Yongjun 
Message-Id: <20211123083618.2366808-1-weiyongjun1@huawei.com>
Signed-off-by: Corey Minyard 
Signed-off-by: Greg Kroah-Hartman

ipmi: Move remove_work to dedicated workqueue

2021-12-08T08:01:10+00:00

commit 1d49eb91e86e8c1c1614c72e3e958b6b7e2472a9 upstream.

Currently when removing an ipmi_user the removal is deferred as a work on
the system's workqueue. Although this guarantees the free operation will
occur in non atomic context, it can race with the ipmi_msghandler module
removal (see [1]) . In case a remove_user work is scheduled for removal
and shortly after ipmi_msghandler module is removed we can end up in a
situation where the module is removed fist and when the work is executed
the system crashes with :
BUG: unable to handle page fault for address: ffffffffc05c3450
PF: supervisor instruction fetch in kernel mode
PF: error_code(0x0010) - not-present page
because the pages of the module are gone. In cleanup_ipmi() there is no
easy way to detect if there are any pending works to flush them before
removing the module. This patch creates a separate workqueue and schedules
the remove_work works on it. When removing the module the workqueue is
drained when destroyed to avoid the race.

[1] https://bugs.launchpad.net/bugs/1950666

Cc: stable@vger.kernel.org # 5.1
Fixes: 3b9a907223d7 (ipmi: fix sleep-in-atomic in free_user at cleanup SRCU user->release_barrier)
Signed-off-by: Ioanna Alifieraki 
Message-Id: <20211115131645.25116-1-ioanna-maria.alifieraki@canonical.com>
Signed-off-by: Corey Minyard 
Signed-off-by: Greg Kroah-Hartman

ipmi: Disable some operations during a panic

2021-11-17T08:48:30+00:00

[ Upstream commit b36eb5e7b75a756baa64909a176dd4269ee05a8b ]

Don't do kfree or other risky things when oops_in_progress is set.
It's easy enough to avoid doing them

Signed-off-by: Corey Minyard 
Signed-off-by: Sasha Levin

ipmi/watchdog: Stop watchdog timer when the current action is 'none'

2021-07-19T06:53:16+00:00

commit 2253042d86f57d90a621ac2513a7a7a13afcf809 upstream.

When an IPMI watchdog timer is being stopped in ipmi_close() or
ipmi_ioctl(WDIOS_DISABLECARD), the current watchdog action is updated to
WDOG_TIMEOUT_NONE and _ipmi_set_timeout(IPMI_SET_TIMEOUT_NO_HB) is called
to install this action. The latter function ends up invoking
__ipmi_set_timeout() which makes the actual 'Set Watchdog Timer' IPMI
request.

For IPMI 1.0, this operation results in fully stopping the watchdog timer.
For IPMI >= 1.5, function __ipmi_set_timeout() always specifies the "don't
stop" flag in the prepared 'Set Watchdog Timer' IPMI request. This causes
that the watchdog timer has its action correctly updated to 'none' but the
timer continues to run. A problem is that IPMI firmware can then still log
an expiration event when the configured timeout is reached, which is
unexpected because the watchdog timer was requested to be stopped.

The patch fixes this problem by not setting the "don't stop" flag in
__ipmi_set_timeout() when the current action is WDOG_TIMEOUT_NONE which
results in stopping the watchdog timer. This makes the behaviour for
IPMI >= 1.5 consistent with IPMI 1.0. It also matches the logic in
__ipmi_heartbeat() which does not allow to reset the watchdog if the
current action is WDOG_TIMEOUT_NONE as that would start the timer.

Signed-off-by: Petr Pavlu 
Message-Id: <10a41bdc-9c99-089c-8d89-fa98ce5ea080@suse.com>
Cc: stable@vger.kernel.org
Signed-off-by: Corey Minyard 
Signed-off-by: Greg Kroah-Hartman

ipmi_si: Fix wrong return value in try_smi_init()

2020-10-29T08:57:44+00:00

[ Upstream commit 8fe7990ceda8597e407d06bffc4bdbe835a93ece ]

On an error exit path, a negative error code should be returned
instead of a positive return value.

Fixes: 90b2d4f15ff7 ("ipmi_si: Remove hacks for adding a dummy platform devices")
Cc: Corey Minyard 
Signed-off-by: Tianjia Zhang 
Message-Id: <20201005145212.84435-1-tianjia.zhang@linux.alibaba.com>
Signed-off-by: Corey Minyard 
Signed-off-by: Sasha Levin

ipmi:bt-bmc: Fix error handling and status check

2020-10-01T11:18:01+00:00

[ Upstream commit 49826937e7c7917140515aaf10c17bedcc4acaad ]

If the function platform_get_irq() failed, the negative value
returned will not be detected here. So fix error handling in
bt_bmc_config_irq(). And in the function bt_bmc_probe(),
when get irq failed, it will print error message. So use
platform_get_irq_optional() to simplify code. Finally in the
function bt_bmc_remove() should make the right status check
if get irq failed.

Signed-off-by: Shengju Zhang 
Signed-off-by: Tang Bin 
Message-Id: <20200505102906.17196-1-tangbin@cmss.chinamobile.com>
[Also set bt_bmc->irq to a negative value if devm_request_irq() fails.]
Signed-off-by: Corey Minyard 
Signed-off-by: Sasha Levin

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