linux.git/drivers/char/ipmi, branch v5.16-rc4 Linux kernel source tree ipmi:ipmb: Fix unknown command response 2021-11-26T03:17:55+00:00 Corey Minyard cminyard@mvista.com 2021-11-25T17:23:20+00:00 c03a487a83fddbca1ef6cb5b97a69cd3e390e233 More missed changes, the response back to another system sending a command that had no user to handle it wasn't formatted properly. Signed-off-by: Corey Minyard <cminyard@mvista.com> 
More missed changes, the response back to another system sending a
command that had no user to handle it wasn't formatted properly.

Signed-off-by: Corey Minyard <cminyard@mvista.com>
ipmi: fix IPMI_SMI_MSG_TYPE_IPMB_DIRECT response length checking 2021-11-26T03:17:55+00:00 Corey Minyard cminyard@mvista.com 2021-11-25T14:47:27+00:00 d2c12f56fa97df216e71437b218ffbeeb4dd46aa A couple of issues: The tested data sizes are wrong; during the design that changed and this got missed. The formatting of the reponse couldn't use the normal one, it has to be an IPMB formatted response. Reported-by: Jakub Kicinski <kuba@kernel.org> Fixes: 059747c245f0 ("ipmi: Add support for IPMB direct messages") Signed-off-by: Corey Minyard <cminyard@mvista.com> 
A couple of issues:

The tested data sizes are wrong; during the design that changed and this
got missed.

The formatting of the reponse couldn't use the normal one, it has to be
an IPMB formatted response.

Reported-by: Jakub Kicinski <kuba@kernel.org>
Fixes: 059747c245f0 ("ipmi: Add support for IPMB direct messages")
Signed-off-by: Corey Minyard <cminyard@mvista.com>
ipmi: fix oob access due to uninit smi_msg type 2021-11-25T14:21:13+00:00 Jakub Kicinski kuba@kernel.org 2021-11-24T21:03:23+00:00 c33fdfbabb6c930454df017f3cd3507dc1a87d09 We're hitting OOB accesses in handle_ipmb_direct_rcv_rsp() (memcpy of size -1) after user space generates a message. Looks like the message is incorrectly assumed to be of the new IPMB type, because type is never set and message is allocated with kmalloc() not kzalloc(). Fixes: 059747c245f0 ("ipmi: Add support for IPMB direct messages") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Message-Id: <20211124210323.1950976-1-kuba@kernel.org> Signed-off-by: Corey Minyard <cminyard@mvista.com> 
We're hitting OOB accesses in handle_ipmb_direct_rcv_rsp() (memcpy of
size -1) after user space generates a message. Looks like the message
is incorrectly assumed to be of the new IPMB type, because type is never
set and message is allocated with kmalloc() not kzalloc().

Fixes: 059747c245f0 ("ipmi: Add support for IPMB direct messages")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Message-Id: <20211124210323.1950976-1-kuba@kernel.org>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
ipmi: msghandler: Make symbol 'remove_work_wq' static 2021-11-23T12:45:00+00:00 Wei Yongjun weiyongjun1@huawei.com 2021-11-23T08:36:18+00:00 5a3ba99b62d8486de0316334e72ac620d4b94fdd 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 <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Message-Id: <20211123083618.2366808-1-weiyongjun1@huawei.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> 
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 <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Message-Id: <20211123083618.2366808-1-weiyongjun1@huawei.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
ipmi: Move remove_work to dedicated workqueue 2021-11-15T14:45:14+00:00 Ioanna Alifieraki ioanna-maria.alifieraki@canonical.com 2021-11-15T13:16:45+00:00 1d49eb91e86e8c1c1614c72e3e958b6b7e2472a9 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 <ioanna-maria.alifieraki@canonical.com> Message-Id: <20211115131645.25116-1-ioanna-maria.alifieraki@canonical.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> 
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 <ioanna-maria.alifieraki@canonical.com>
Message-Id: <20211115131645.25116-1-ioanna-maria.alifieraki@canonical.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
ipmi: kcs_bmc: Fix a memory leak in the error handling path of 'kcs_bmc_serio_add_device()' 2021-10-29T12:23:59+00:00 Christophe JAILLET christophe.jaillet@wanadoo.fr 2021-09-07T21:06:32+00:00 f281d010b87454e72475b668ad66e34961f744e0 In the unlikely event where 'devm_kzalloc()' fails and 'kzalloc()' succeeds, 'port' would be leaking. Test each allocation separately to avoid the leak. Fixes: 3a3d2f6a4c64 ("ipmi: kcs_bmc: Add serio adaptor") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Message-Id: <ecbfa15e94e64f4b878ecab1541ea46c74807670.1631048724.git.christophe.jaillet@wanadoo.fr> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Signed-off-by: Corey Minyard <cminyard@mvista.com> 
In the unlikely event where 'devm_kzalloc()' fails and 'kzalloc()'
succeeds, 'port' would be leaking.

Test each allocation separately to avoid the leak.

Fixes: 3a3d2f6a4c64 ("ipmi: kcs_bmc: Add serio adaptor")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Message-Id: <ecbfa15e94e64f4b878ecab1541ea46c74807670.1631048724.git.christophe.jaillet@wanadoo.fr>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
char: ipmi: replace snprintf in show functions with sysfs_emit 2021-10-21T11:54:12+00:00 Ye Guojin ye.guojin@zte.com.cn 2021-10-21T11:06:08+00:00 fc4e78481afa33585195e896f0f9d9cec1129c80 coccicheck complains about the use of snprintf() in sysfs show functions: WARNING use scnprintf or sprintf Use sysfs_emit instead of scnprintf, snprintf or sprintf makes more sense. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Ye Guojin <ye.guojin@zte.com.cn> Message-Id: <20211021110608.1060260-1-ye.guojin@zte.com.cn> Signed-off-by: Corey Minyard <cminyard@mvista.com> 
coccicheck complains about the use of snprintf() in sysfs show
functions:
WARNING  use scnprintf or sprintf

Use sysfs_emit instead of scnprintf, snprintf or sprintf makes more
sense.

Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Ye Guojin <ye.guojin@zte.com.cn>
Message-Id: <20211021110608.1060260-1-ye.guojin@zte.com.cn>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
ipmi: ipmb: fix dependencies to eliminate build error 2021-10-14T16:17:18+00:00 Randy Dunlap rdunlap@infradead.org 2021-10-12T20:44:16+00:00 ed83855f1efceda932a121b9fb13d08b27427f9b When CONFIG_I2C=m, CONFIG_I2C_SLAVE=y (bool), and CONFIG_IPMI_IPMB=y, the build fails with: ld: drivers/char/ipmi/ipmi_ipmb.o: in function `ipmi_ipmb_remove': ipmi_ipmb.c:(.text+0x6b): undefined reference to `i2c_slave_unregister' ld: drivers/char/ipmi/ipmi_ipmb.o: in function `ipmi_ipmb_thread': ipmi_ipmb.c:(.text+0x2a4): undefined reference to `i2c_transfer' ld: drivers/char/ipmi/ipmi_ipmb.o: in function `ipmi_ipmb_probe': ipmi_ipmb.c:(.text+0x646): undefined reference to `i2c_slave_register' ld: drivers/char/ipmi/ipmi_ipmb.o: in function `ipmi_ipmb_driver_init': ipmi_ipmb.c:(.init.text+0xa): undefined reference to `i2c_register_driver' ld: drivers/char/ipmi/ipmi_ipmb.o: in function `ipmi_ipmb_driver_exit': ipmi_ipmb.c:(.exit.text+0x8): undefined reference to `i2c_del_driver' This is due to having a tristate depending on a bool symbol. By adding I2C (tristate) as a dependency, the desired dependencies are met, causing IPMI_IPMB to be changed from =y to =m: -CONFIG_IPMI_IPMB=y +CONFIG_IPMI_IPMB=m Fixes: 63c4eb347164 ("ipmi:ipmb: Add initial support for IPMI over IPMB") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Corey Minyard <minyard@acm.org> Cc: openipmi-developer@lists.sourceforge.net Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Message-Id: <20211012204416.23108-1-rdunlap@infradead.org> Signed-off-by: Corey Minyard <cminyard@mvista.com> 
When CONFIG_I2C=m, CONFIG_I2C_SLAVE=y (bool), and CONFIG_IPMI_IPMB=y,
the build fails with:

ld: drivers/char/ipmi/ipmi_ipmb.o: in function `ipmi_ipmb_remove':
ipmi_ipmb.c:(.text+0x6b): undefined reference to `i2c_slave_unregister'
ld: drivers/char/ipmi/ipmi_ipmb.o: in function `ipmi_ipmb_thread':
ipmi_ipmb.c:(.text+0x2a4): undefined reference to `i2c_transfer'
ld: drivers/char/ipmi/ipmi_ipmb.o: in function `ipmi_ipmb_probe':
ipmi_ipmb.c:(.text+0x646): undefined reference to `i2c_slave_register'
ld: drivers/char/ipmi/ipmi_ipmb.o: in function `ipmi_ipmb_driver_init':
ipmi_ipmb.c:(.init.text+0xa): undefined reference to `i2c_register_driver'
ld: drivers/char/ipmi/ipmi_ipmb.o: in function `ipmi_ipmb_driver_exit':
ipmi_ipmb.c:(.exit.text+0x8): undefined reference to `i2c_del_driver'

This is due to having a tristate depending on a bool symbol.
By adding I2C (tristate) as a dependency, the desired dependencies
are met, causing IPMI_IPMB to be changed from =y to =m:

  -CONFIG_IPMI_IPMB=y
  +CONFIG_IPMI_IPMB=m

Fixes: 63c4eb347164 ("ipmi:ipmb: Add initial support for IPMI over IPMB")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Corey Minyard <minyard@acm.org>
Cc: openipmi-developer@lists.sourceforge.net
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Message-Id: <20211012204416.23108-1-rdunlap@infradead.org>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
ipmi:ipmb: Add OF support 2021-10-14T16:17:18+00:00 Corey Minyard cminyard@mvista.com 2021-10-12T21:36:07+00:00 3a076b307c2250f44d2bbe72a3817d6a61793756 Add direct OF support for fetching control parameters from the device tree. Make it work like the device tree entries for the other IPMI devices. Also add documentation for this. Signed-off-by: Corey Minyard <cminyard@mvista.com> 
Add direct OF support for fetching control parameters from the device
tree.  Make it work like the device tree entries for the other IPMI
devices.  Also add documentation for this.

Signed-off-by: Corey Minyard <cminyard@mvista.com>
ipmi: bt: Add ast2600 compatible string 2021-10-07T19:02:45+00:00 Joel Stanley joel@jms.id.au 2021-09-03T01:53:14+00:00 cd921b9f0c8d0a198eaeb897fc4124a73b742b4b The AST2600 has the same register set as the previous generation SoCs. Signed-off-by: Joel Stanley <joel@jms.id.au> Acked-by: Rob Herring <robh@kernel.org> Message-Id: <20210903015314.177987-1-joel@jms.id.au> Signed-off-by: Corey Minyard <cminyard@mvista.com> 
The AST2600 has the same register set as the previous generation SoCs.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Acked-by: Rob Herring <robh@kernel.org>
Message-Id: <20210903015314.177987-1-joel@jms.id.au>
Signed-off-by: Corey Minyard <cminyard@mvista.com>