kernel/drivers/char/ipmi, branch linux-5.1.y

ipmi:ssif: compare block number correctly for multi-part return messages

2019-05-22T05:39:55Z

commit 55be8658c7e2feb11a5b5b33ee031791dbd23a69 upstream. According to ipmi spec, block number is a number that is incremented, starting with 0, for each new block of message data returned using the middle transaction. Here, the 'blocknum' is data[0] which always starts from zero(0) and 'ssif_info->multi_pos' starts from 1. So, we need to add +1 to blocknum while comparing with multi_pos. Fixes: 7d6380cd40f79 ("ipmi:ssif: Fix handling of multi-part return messages"). Reported-by: Kiran Kolukuluru Signed-off-by: Kamlakant Patel Message-Id: <1556106615-18722-1-git-send-email-kamlakantp@marvell.com> [Also added a debug log if the block numbers don't match.] Signed-off-by: Corey Minyard Cc: stable@vger.kernel.org # 4.4 Signed-off-by: Greg Kroah-Hartman

ipmi: Add the i2c-addr property for SSIF interfaces

2019-05-22T05:39:55Z

commit d73236383eb1cd4b7b65c33a09f0ed45f6781f40 upstream. This is required for SSIF to work. There was no way to know if the interface being added was SI or SSIF from the platform data, but that was required so the i2c-addr is only added for SSIF interfaces. So add a field for that. Also rework the logic a bit so that ipmi-type is not set for SSIF interfaces, as it is not necessary for that. Fixes: 3cd83bac481d ("ipmi: Consolidate the adding of platform devices") Reported-by: Kamlakant Patel Signed-off-by: Corey Minyard Cc: stable@vger.kernel.org # 5.1 Signed-off-by: Greg Kroah-Hartman

ipmi: fix sleep-in-atomic in free_user at cleanup SRCU user->release_barrier

2019-04-17T15:29:27Z

free_user() could be called in atomic context. This patch pushed the free operation off into a workqueue. Example: BUG: sleeping function called from invalid context at kernel/workqueue.c:2856 in_atomic(): 1, irqs_disabled(): 0, pid: 177, name: ksoftirqd/27 CPU: 27 PID: 177 Comm: ksoftirqd/27 Not tainted 4.19.25-3 #1 Hardware name: AIC 1S-HV26-08/MB-DPSB04-06, BIOS IVYBV060 10/21/2015 Call Trace: dump_stack+0x5c/0x7b ___might_sleep+0xec/0x110 __flush_work+0x48/0x1f0 ? try_to_del_timer_sync+0x4d/0x80 _cleanup_srcu_struct+0x104/0x140 free_user+0x18/0x30 [ipmi_msghandler] ipmi_free_recv_msg+0x3a/0x50 [ipmi_msghandler] deliver_response+0xbd/0xd0 [ipmi_msghandler] deliver_local_response+0xe/0x30 [ipmi_msghandler] handle_one_recv_msg+0x163/0xc80 [ipmi_msghandler] ? dequeue_entity+0xa0/0x960 handle_new_recv_msgs+0x15c/0x1f0 [ipmi_msghandler] tasklet_action_common.isra.22+0x103/0x120 __do_softirq+0xf8/0x2d7 run_ksoftirqd+0x26/0x50 smpboot_thread_fn+0x11d/0x1e0 kthread+0x103/0x140 ? sort_range+0x20/0x20 ? kthread_destroy_worker+0x40/0x40 ret_from_fork+0x1f/0x40 Fixes: 77f8269606bf ("ipmi: fix use-after-free of user->release_barrier.rda") Reported-by: Konstantin Khlebnikov Signed-off-by: Corey Minyard Cc: stable@vger.kernel.org # 5.0 Cc: Yang Yingliang

ipmi: ipmi_si_hardcode.c: init si_type array to fix a crash

2019-04-16T21:36:49Z

The intended behavior of function ipmi_hardcode_init_one() is to default to kcs interface when no type argument is presented when initializing ipmi with hard coded addresses. However, the array of char pointers allocated on the stack by function ipmi_hardcode_init() was not inited to zeroes, so it contained stack debris. Consequently, passing the cruft stored in this array to function ipmi_hardcode_init_one() caused a crash when it was unable to detect that the char * being passed was nonsense and tried to access the address specified by the bogus pointer. The fix is simply to initialize the si_type array to zeroes, so if there were no type argument given to at the command line, function ipmi_hardcode_init_one() could properly default to the kcs interface. Signed-off-by: Tony Camuso Message-Id: <1554837603-40299-1-git-send-email-tcamuso@redhat.com> Signed-off-by: Corey Minyard

ipmi: Fix failure on SMBIOS specified devices

2019-04-16T21:36:47Z

An extra memset was put into a place that cleared the interface type. Reported-by: Tony Camuso Fixes: 3cd83bac481dc4 ("ipmi: Consolidate the adding of platform devices") Signed-off-by: Corey Minyard

ipmi_si: Potential array underflow in hotmod_handler()

2019-02-22T20:59:25Z

The "ival" variable needs to signed so that we don't read before the start of the str[] array. This would only happen the user passed in a module parameter that was just comprised of space characters. Fixes: e80444ae4fc3 ("ipmi_si: Switch hotmod to use a platform device") Signed-off-by: Dan Carpenter Message-Id: <20190222195530.GA306@kadam> Signed-off-by: Corey Minyard

ipmi_si: Remove hacks for adding a dummy platform devices

2019-02-22T13:12:41Z

All the IPMI address sources now supply a real device. This cheap hack is no longer necessary. Signed-off-by: Corey Minyard

ipmi_si: Consolidate scanning the platform bus

2019-02-22T13:12:41Z

The same basic code was in two places. Signed-off-by: Corey Minyard

ipmi_si: Remove hotmod devices on removal and exit

2019-02-22T13:12:41Z

When a hotmod-added device is removed or when the module is removed, remove the platform devices that was created for it. Signed-off-by: Corey Minyard

ipmi_si: Remove hardcode IPMI devices by scanning the platform bus

2019-02-22T13:12:41Z

Instead of keeping track of each one, just scan the platform bus for hardcode devices and remove them. Signed-off-by: Corey Minyard