linux-toradex.git/drivers/char/ipmi/ipmi_ssif.c, branch v5.16 Linux kernel for Apalis and Colibri modules ipmi: ssif: initialize ssif_info->client early 2021-12-08T13:13:37+00:00 Mian Yousaf Kaukab ykaukab@suse.de 2021-12-08T09:32:39+00:00 34f35f8f14bc406efc06ee4ff73202c6fd245d15 During probe ssif_info->client is dereferenced in error path. However, it is set when some of the error checking has already been done. This causes following kernel crash if an error path is taken: [ 30.645593][ T674] ipmi_ssif 0-000e: ipmi_ssif: Not probing, Interface already present [ 30.657616][ T674] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088 ... [ 30.657723][ T674] pc : __dev_printk+0x28/0xa0 [ 30.657732][ T674] lr : _dev_err+0x7c/0xa0 ... [ 30.657772][ T674] Call trace: [ 30.657775][ T674] __dev_printk+0x28/0xa0 [ 30.657778][ T674] _dev_err+0x7c/0xa0 [ 30.657781][ T674] ssif_probe+0x548/0x900 [ipmi_ssif 62ce4b08badc1458fd896206d9ef69a3c31f3d3e] [ 30.657791][ T674] i2c_device_probe+0x37c/0x3c0 ... Initialize ssif_info->client before any error path can be taken. Clear i2c_client data in the error path to prevent the dangling pointer from leaking. Fixes: c4436c9149c5 ("ipmi_ssif: avoid registering duplicate ssif interface") Cc: stable@vger.kernel.org # 5.4.x Suggested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de> Message-Id: <20211208093239.4432-1-ykaukab@suse.de> Signed-off-by: Corey Minyard <cminyard@mvista.com> 
During probe ssif_info->client is dereferenced in error path. However,
it is set when some of the error checking has already been done. This
causes following kernel crash if an error path is taken:

[   30.645593][  T674] ipmi_ssif 0-000e: ipmi_ssif: Not probing, Interface already present
[   30.657616][  T674] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088
...
[   30.657723][  T674] pc : __dev_printk+0x28/0xa0
[   30.657732][  T674] lr : _dev_err+0x7c/0xa0
...
[   30.657772][  T674] Call trace:
[   30.657775][  T674]  __dev_printk+0x28/0xa0
[   30.657778][  T674]  _dev_err+0x7c/0xa0
[   30.657781][  T674]  ssif_probe+0x548/0x900 [ipmi_ssif 62ce4b08badc1458fd896206d9ef69a3c31f3d3e]
[   30.657791][  T674]  i2c_device_probe+0x37c/0x3c0
...

Initialize ssif_info->client before any error path can be taken. Clear
i2c_client data in the error path to prevent the dangling pointer from
leaking.

Fixes: c4436c9149c5 ("ipmi_ssif: avoid registering duplicate ssif interface")
Cc: stable@vger.kernel.org # 5.4.x
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de>
Message-Id: <20211208093239.4432-1-ykaukab@suse.de>
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:ssif: make ssif_i2c_send() void 2021-03-11T01:00:02+00:00 Liguang Zhang zhangliguang@linux.alibaba.com 2021-03-01T14:05:15+00:00 dcd10526ac5a0d6cc94ce60b9acfca458163277b This function actually needs no return value. So remove the unneeded check and make it void. Signed-off-by: Liguang Zhang <zhangliguang@linux.alibaba.com> Message-Id: <20210301140515.18951-1-zhangliguang@linux.alibaba.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> 
This function actually needs no return value. So remove the unneeded
check and make it void.

Signed-off-by: Liguang Zhang <zhangliguang@linux.alibaba.com>
Message-Id: <20210301140515.18951-1-zhangliguang@linux.alibaba.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
ipmi: ssif: Remove finished TODO comment about SMBus alert 2020-06-24T11:41:42+00:00 Misono Tomohiro misono.tomohiro@jp.fujitsu.com 2020-06-24T06:54:04+00:00 29a54910152adf9bba4eefbe5e4cd071291775a4 commit 9162052173d2 ("ipmi: Add alert handling to SSIF") introduces support of SMBus alert. So, just remove TODO comment in order not to confuse future readers. Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com> Message-Id: <20200624065405.17653-2-misono.tomohiro@jp.fujitsu.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> 
commit 9162052173d2 ("ipmi: Add alert handling to SSIF") introduces
support of SMBus alert. So, just remove TODO comment in order not to
confuse future readers.

Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
Message-Id: <20200624065405.17653-2-misono.tomohiro@jp.fujitsu.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
ipmi:ssif: Remove dynamic platform device handing 2020-05-27T23:25:56+00:00 Corey Minyard cminyard@mvista.com 2020-05-27T23:25:56+00:00 2a556ce779e39b15cbb74e896ca640e86baeb1a1 Platform devices can only come in through the DMI interface, and that will get done before initialization is complete. Therefore there is no reason to hande getting a device in new_ssif_client after initialization. Dynamic entries can still come in through the i2c interfaces, but that's handled differently. Signed-off-by: Corey Minyard <cminyard@mvista.com> 
Platform devices can only come in through the DMI interface, and that
will get done before initialization is complete.  Therefore there is no
reason to hande getting a device in new_ssif_client after
initialization.

Dynamic entries can still come in through the i2c interfaces, but that's
handled differently.

Signed-off-by: Corey Minyard <cminyard@mvista.com>
Try to load acpi_ipmi when an SSIF ACPI IPMI interface is added 2020-05-18T11:32:02+00:00 Corey Minyard cminyard@mvista.com 2020-05-11T21:13:59+00:00 e641abd3c7261741f295d41d80b213c20f127de2 This is similar to the recent patch for the SI interface, but for SSIF. Signed-off-by: Corey Minyard <cminyard@mvista.com> 
This is similar to the recent patch for the SI interface, but for SSIF.

Signed-off-by: Corey Minyard <cminyard@mvista.com>
char: ipmi: convert to use i2c_new_client_device() 2020-05-14T20:37:31+00:00 Wolfram Sang wsa+renesas@sang-engineering.com 2020-03-26T21:09:58+00:00 653d374771601a345296dd2904a10e6e479ad866 Move away from the deprecated API. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Message-Id: <20200326210958.13051-2-wsa+renesas@sang-engineering.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> 
Move away from the deprecated API.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Message-Id: <20200326210958.13051-2-wsa+renesas@sang-engineering.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
ipmi: Add missing annotation for ipmi_ssif_lock_cond() and ipmi_ssif_unlock_cond() 2020-04-03T18:34:57+00:00 Jules Irenge jbi.octave@gmail.com 2020-04-03T16:05:05+00:00 562bf7705885855ed8ed5483895ddff509acae7c Sparse reports a warning at ipmi_ssif_unlock_cond() and ipmi_ssif_lock_cond() warning: context imbalance in ipmi_ssif_lock_cond() - wrong count at exit warning: context imbalance in ipmi_ssif_unlock_cond() - unexpected unlock The root cause is the missing annotation at ipmi_ssif_unlock_cond() and ipmi_ssif_lock_cond() Add the missing __acquires(&ata_scsi_rbuf_lock) Add the missing __releases(&ata_scsi_rbuf_lock) Signed-off-by: Jules Irenge <jbi.octave@gmail.com> Message-Id: <20200403160505.2832-6-jbi.octave@gmail.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> 
Sparse reports a warning at ipmi_ssif_unlock_cond()
	and ipmi_ssif_lock_cond()

warning: context imbalance in ipmi_ssif_lock_cond()
	- wrong count at exit
 warning: context imbalance in ipmi_ssif_unlock_cond()
	- unexpected unlock

The root cause is the missing annotation at ipmi_ssif_unlock_cond()
	and ipmi_ssif_lock_cond()

Add the missing __acquires(&ata_scsi_rbuf_lock)
Add the missing __releases(&ata_scsi_rbuf_lock)

Signed-off-by: Jules Irenge <jbi.octave@gmail.com>
Message-Id: <20200403160505.2832-6-jbi.octave@gmail.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
ipmi:ssif: Handle a possible NULL pointer reference 2019-12-23T16:42:19+00:00 Corey Minyard cminyard@mvista.com 2019-12-23T16:42:19+00:00 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 <lkp@intel.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> 
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 <lkp@intel.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
ipmi_ssif: avoid registering duplicate ssif interface 2019-08-22T16:06:33+00:00 Kamlakant Patel kamlakantp@marvell.com 2019-08-21T12:04:33+00:00 c4436c9149c5d2bc0c49ab57ec85c75ea1c4d61c 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 <kamlakantp@marvell.com> Message-Id: <1566389064-27356-1-git-send-email-kamlakantp@marvell.com> Signed-off-by: Corey Minyard <cminyard@mvista.com> 
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 <kamlakantp@marvell.com>
Message-Id: <1566389064-27356-1-git-send-email-kamlakantp@marvell.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>