<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/char/ipmi, branch v5.4.3</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.3</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.3'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2019-09-12T21:03:18Z</updated>
<entry>
<title>ipmi_si_intf: Fix race in timer shutdown handling</title>
<updated>2019-09-12T21:03:18Z</updated>
<author>
<name>Jes Sorensen</name>
<email>jsorensen@fb.com</email>
</author>
<published>2019-08-28T20:36:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c9acc3c4f8e42ae538aea7f418fddc16f257ba75'/>
<id>urn:sha1:c9acc3c4f8e42ae538aea7f418fddc16f257ba75</id>
<content type='text'>
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 &lt;jsorensen@fb.com&gt;
Message-Id: &lt;20190828203625.32093-2-Jes.Sorensen@gmail.com&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</content>
</entry>
<entry>
<title>ipmi: move message error checking to avoid deadlock</title>
<updated>2019-08-22T16:08:13Z</updated>
<author>
<name>Tony Camuso</name>
<email>tcamuso@redhat.com</email>
</author>
<published>2019-08-22T12:24:53Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=383035211c79d4d98481a09ad429b31c7dbf22bd'/>
<id>urn:sha1:383035211c79d4d98481a09ad429b31c7dbf22bd</id>
<content type='text'>
V1-&gt;V2: in handle_one_rcv_msg, if data_size &gt; 2, set requeue to zero and
        goto out instead of calling ipmi_free_msg.
        Kosuke Tatsukawa &lt;tatsu@ab.jp.nec.com&gt;

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 &lt;cminyard@mvista.com&gt;
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 &lt;tatsu@ab.jp.nec.com&gt; 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 &lt;osa-samukawa@tg.jp.nec.com&gt;
Characterized by: Kosuke Tatsukawa &lt;tatsu@ab.jp.nec.com&gt;
Signed-off-by: Tony Camuso &lt;tcamuso@redhat.com&gt;
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 &lt;cminyard@mvista.com&gt;
</content>
</entry>
<entry>
<title>ipmi_ssif: avoid registering duplicate ssif interface</title>
<updated>2019-08-22T16:06:33Z</updated>
<author>
<name>Kamlakant Patel</name>
<email>kamlakantp@marvell.com</email>
</author>
<published>2019-08-21T12:04:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c4436c9149c5d2bc0c49ab57ec85c75ea1c4d61c'/>
<id>urn:sha1:c4436c9149c5d2bc0c49ab57ec85c75ea1c4d61c</id>
<content type='text'>
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 &lt;kamlakantp@marvell.com&gt;
Message-Id: &lt;1566389064-27356-1-git-send-email-kamlakantp@marvell.com&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</content>
</entry>
<entry>
<title>ipmi: Free receive messages when in an oops</title>
<updated>2019-08-16T21:18:18Z</updated>
<author>
<name>Corey Minyard</name>
<email>cminyard@mvista.com</email>
</author>
<published>2019-08-16T21:13:42Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2033f6858970b98c18bed4d5ae68f43d17400abc'/>
<id>urn:sha1:2033f6858970b98c18bed4d5ae68f43d17400abc</id>
<content type='text'>
If the driver handles a response in an oops, it was just ignoring
the message.  However, the IPMI watchdog timer was counting on the
free happening to know when panic-time messages were complete.  So
free it in all cases.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</content>
</entry>
<entry>
<title>ipmi_si: Only schedule continuously in the thread in maintenance mode</title>
<updated>2019-08-05T21:17:27Z</updated>
<author>
<name>Corey Minyard</name>
<email>cminyard@mvista.com</email>
</author>
<published>2019-08-02T12:31:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=340ff31ab00bca5c15915e70ad9ada3030c98cf8'/>
<id>urn:sha1:340ff31ab00bca5c15915e70ad9ada3030c98cf8</id>
<content type='text'>
ipmi_thread() uses back-to-back schedule() to poll for command
completion which, on some machines, can push up CPU consumption and
heavily tax the scheduler locks leading to noticeable overall
performance degradation.

This was originally added so firmware updates through IPMI would
complete in a timely manner.  But we can't kill the scheduler
locks for that one use case.

Instead, only run schedule() continuously in maintenance mode,
where firmware updates should run.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</content>
</entry>
<entry>
<title>ipmi_si: Remove ipmi_ from the device attr names</title>
<updated>2019-08-02T12:26:36Z</updated>
<author>
<name>Corey Minyard</name>
<email>cminyard@mvista.com</email>
</author>
<published>2019-08-01T00:46:53Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=93b6984b31182cfc340495af17691c0b9d53f6b2'/>
<id>urn:sha1:93b6984b31182cfc340495af17691c0b9d53f6b2</id>
<content type='text'>
Better conform with kernel style.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</content>
</entry>
<entry>
<title>ipmi_si: Convert device attr permissions to octal</title>
<updated>2019-08-02T12:25:44Z</updated>
<author>
<name>Corey Minyard</name>
<email>cminyard@mvista.com</email>
</author>
<published>2019-08-01T00:37:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a6f4c33187d038dc2ca4ab885eb5e9c44940760f'/>
<id>urn:sha1:a6f4c33187d038dc2ca4ab885eb5e9c44940760f</id>
<content type='text'>
Kernel preferences are for octal values instead of symbols.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</content>
</entry>
<entry>
<title>ipmi_si: Rework some include files</title>
<updated>2019-08-02T12:25:03Z</updated>
<author>
<name>Corey Minyard</name>
<email>cminyard@mvista.com</email>
</author>
<published>2019-08-01T00:18:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=104fb25f60077e4696145bcea51ca56f0959d7e3'/>
<id>urn:sha1:104fb25f60077e4696145bcea51ca56f0959d7e3</id>
<content type='text'>
ipmi_si_sm.h was getting included in lots of places it didn't
belong.  Rework things a bit to remove all the dependencies,
mostly just moving things between include files that were in
the wrong place and removing bogus includes.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</content>
</entry>
<entry>
<title>ipmi_si: Convert timespec64 to timespec</title>
<updated>2019-08-01T00:52:29Z</updated>
<author>
<name>Corey Minyard</name>
<email>cminyard@mvista.com</email>
</author>
<published>2019-07-31T20:33:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cbb19cb1eef050b193c823502bf920097c0f0459'/>
<id>urn:sha1:cbb19cb1eef050b193c823502bf920097c0f0459</id>
<content type='text'>
There is no need for timespec64, and it will cause issues in the
future with i386 and 64-bit division not being available.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</content>
</entry>
<entry>
<title>Fix uninitialized variable in ipmb_dev_int.c</title>
<updated>2019-07-24T20:53:21Z</updated>
<author>
<name>Asmaa Mnebhi</name>
<email>Asmaa@mellanox.com</email>
</author>
<published>2019-07-24T19:32:57Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=71be7b0e7d4069822c89146daed800686db8f147'/>
<id>urn:sha1:71be7b0e7d4069822c89146daed800686db8f147</id>
<content type='text'>
ret at line 112 of ipmb_dev_int.c is uninitialized which
results in a warning during build regressions.
This warning was found by build regression/improvement
testing for v5.3-rc1.

Reported-by: build regression/improvement testing for v5.3-rc1.
Fixes: 51bd6f291583 ("Add support for IPMB driver")
Signed-off-by: Asmaa Mnebhi &lt;Asmaa@mellanox.com&gt;
Message-Id: &lt;571dbb67cf58411d567953d9fb3739eb4789238b.1563996586.git.Asmaa@mellanox.com&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</content>
</entry>
</feed>
