<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/char/ipmi, branch v4.1.41</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ipmi: Fix kernel panic at ipmi_ssif_thread()</title>
<updated>2017-05-17T19:08:21+00:00</updated>
<author>
<name>Joeseph Chang</name>
<email>joechang@codeaurora.org</email>
</author>
<published>2017-03-28T02:22:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=21ebc869930ae5d0c086d27dbe05be9fd7cf5e85'/>
<id>21ebc869930ae5d0c086d27dbe05be9fd7cf5e85</id>
<content type='text'>
[ Upstream commit 6de65fcfdb51835789b245203d1bfc8d14cb1e06 ]

msg_written_handler() may set ssif_info-&gt;multi_data to NULL
when using ipmitool to write fru.

Before setting ssif_info-&gt;multi_data to NULL, add new local
pointer "data_to_send" and store correct i2c data pointer to
it to fix NULL pointer kernel panic and incorrect ssif_info-&gt;multi_pos.

Signed-off-by: Joeseph Chang &lt;joechang@codeaurora.org&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
Cc: stable@vger.kernel.org # 3.19-
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 6de65fcfdb51835789b245203d1bfc8d14cb1e06 ]

msg_written_handler() may set ssif_info-&gt;multi_data to NULL
when using ipmitool to write fru.

Before setting ssif_info-&gt;multi_data to NULL, add new local
pointer "data_to_send" and store correct i2c data pointer to
it to fix NULL pointer kernel panic and incorrect ssif_info-&gt;multi_pos.

Signed-off-by: Joeseph Chang &lt;joechang@codeaurora.org&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
Cc: stable@vger.kernel.org # 3.19-
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipmi: Remove smi_msg from waiting_rcv_msgs list before handle_one_recv_msg()</title>
<updated>2016-07-11T00:19:55+00:00</updated>
<author>
<name>Junichi Nomura</name>
<email>j-nomura@ce.jp.nec.com</email>
</author>
<published>2016-06-10T04:31:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7ac3a704d7dd6c0b8a72048ee66523f190afda8d'/>
<id>7ac3a704d7dd6c0b8a72048ee66523f190afda8d</id>
<content type='text'>
[ Upstream commit ae4ea9a2460c7fee2ae8feeb4dfe96f5f6c3e562 ]

Commit 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for
SMI interfaces") changed handle_new_recv_msgs() to call handle_one_recv_msg()
for a smi_msg while the smi_msg is still connected to waiting_rcv_msgs list.
That could lead to following list corruption problems:

1) low-level function treats smi_msg as not connected to list

  handle_one_recv_msg() could end up calling smi_send(), which
  assumes the msg is not connected to list.

  For example, the following sequence could corrupt list by
  doing list_add_tail() for the entry still connected to other list.

    handle_new_recv_msgs()
      msg = list_entry(waiting_rcv_msgs)
      handle_one_recv_msg(msg)
        handle_ipmb_get_msg_cmd(msg)
          smi_send(msg)
            spin_lock(xmit_msgs_lock)
            list_add_tail(msg)
            spin_unlock(xmit_msgs_lock)

2) race between multiple handle_new_recv_msgs() instances

  handle_new_recv_msgs() once releases waiting_rcv_msgs_lock before calling
  handle_one_recv_msg() then retakes the lock and list_del() it.

  If others call handle_new_recv_msgs() during the window shown below
  list_del() will be done twice for the same smi_msg.

  handle_new_recv_msgs()
    spin_lock(waiting_rcv_msgs_lock)
    msg = list_entry(waiting_rcv_msgs)
    spin_unlock(waiting_rcv_msgs_lock)
  |
  | handle_one_recv_msg(msg)
  |
    spin_lock(waiting_rcv_msgs_lock)
    list_del(msg)
    spin_unlock(waiting_rcv_msgs_lock)

Fixes: 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for SMI interfaces")
Signed-off-by: Jun'ichi Nomura &lt;j-nomura@ce.jp.nec.com&gt;
[Added a comment to describe why this works.]
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
Cc: stable@vger.kernel.org # 3.19
Tested-by: Ye Feng &lt;yefeng.yl@alibaba-inc.com&gt;

Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit ae4ea9a2460c7fee2ae8feeb4dfe96f5f6c3e562 ]

Commit 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for
SMI interfaces") changed handle_new_recv_msgs() to call handle_one_recv_msg()
for a smi_msg while the smi_msg is still connected to waiting_rcv_msgs list.
That could lead to following list corruption problems:

1) low-level function treats smi_msg as not connected to list

  handle_one_recv_msg() could end up calling smi_send(), which
  assumes the msg is not connected to list.

  For example, the following sequence could corrupt list by
  doing list_add_tail() for the entry still connected to other list.

    handle_new_recv_msgs()
      msg = list_entry(waiting_rcv_msgs)
      handle_one_recv_msg(msg)
        handle_ipmb_get_msg_cmd(msg)
          smi_send(msg)
            spin_lock(xmit_msgs_lock)
            list_add_tail(msg)
            spin_unlock(xmit_msgs_lock)

2) race between multiple handle_new_recv_msgs() instances

  handle_new_recv_msgs() once releases waiting_rcv_msgs_lock before calling
  handle_one_recv_msg() then retakes the lock and list_del() it.

  If others call handle_new_recv_msgs() during the window shown below
  list_del() will be done twice for the same smi_msg.

  handle_new_recv_msgs()
    spin_lock(waiting_rcv_msgs_lock)
    msg = list_entry(waiting_rcv_msgs)
    spin_unlock(waiting_rcv_msgs_lock)
  |
  | handle_one_recv_msg(msg)
  |
    spin_lock(waiting_rcv_msgs_lock)
    list_del(msg)
    spin_unlock(waiting_rcv_msgs_lock)

Fixes: 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for SMI interfaces")
Signed-off-by: Jun'ichi Nomura &lt;j-nomura@ce.jp.nec.com&gt;
[Added a comment to describe why this works.]
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
Cc: stable@vger.kernel.org # 3.19
Tested-by: Ye Feng &lt;yefeng.yl@alibaba-inc.com&gt;

Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipmi: move timer init to before irq is setup</title>
<updated>2016-01-31T19:23:31+00:00</updated>
<author>
<name>Jan Stancek</name>
<email>jstancek@redhat.com</email>
</author>
<published>2015-12-08T18:57:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=69bed67bc32fd47774539eaddb9f33420df556fe'/>
<id>69bed67bc32fd47774539eaddb9f33420df556fe</id>
<content type='text'>
commit 27f972d3e00b50639deb4cc1392afaeb08d3cecc upstream.

We encountered a panic on boot in ipmi_si on a dell per320 due to an
uninitialized timer as follows.

static int smi_start_processing(void       *send_info,
                                ipmi_smi_t intf)
{
        /* Try to claim any interrupts. */
        if (new_smi-&gt;irq_setup)
                new_smi-&gt;irq_setup(new_smi);

 --&gt; IRQ arrives here and irq handler tries to modify uninitialized timer

    which triggers BUG_ON(!timer-&gt;function) in __mod_timer().

 Call Trace:
   &lt;IRQ&gt;
   [&lt;ffffffffa0532617&gt;] start_new_msg+0x47/0x80 [ipmi_si]
   [&lt;ffffffffa053269e&gt;] start_check_enables+0x4e/0x60 [ipmi_si]
   [&lt;ffffffffa0532bd8&gt;] smi_event_handler+0x1e8/0x640 [ipmi_si]
   [&lt;ffffffff810f5584&gt;] ? __rcu_process_callbacks+0x54/0x350
   [&lt;ffffffffa053327c&gt;] si_irq_handler+0x3c/0x60 [ipmi_si]
   [&lt;ffffffff810efaf0&gt;] handle_IRQ_event+0x60/0x170
   [&lt;ffffffff810f245e&gt;] handle_edge_irq+0xde/0x180
   [&lt;ffffffff8100fc59&gt;] handle_irq+0x49/0xa0
   [&lt;ffffffff8154643c&gt;] do_IRQ+0x6c/0xf0
   [&lt;ffffffff8100ba53&gt;] ret_from_intr+0x0/0x11

        /* Set up the timer that drives the interface. */
        setup_timer(&amp;new_smi-&gt;si_timer, smi_timeout, (long)new_smi);

The following patch fixes the problem.

To: Openipmi-developer@lists.sourceforge.net
To: Corey Minyard &lt;minyard@acm.org&gt;
CC: linux-kernel@vger.kernel.org

Signed-off-by: Jan Stancek &lt;jstancek@redhat.com&gt;
Signed-off-by: Tony Camuso &lt;tcamuso@redhat.com&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 27f972d3e00b50639deb4cc1392afaeb08d3cecc upstream.

We encountered a panic on boot in ipmi_si on a dell per320 due to an
uninitialized timer as follows.

static int smi_start_processing(void       *send_info,
                                ipmi_smi_t intf)
{
        /* Try to claim any interrupts. */
        if (new_smi-&gt;irq_setup)
                new_smi-&gt;irq_setup(new_smi);

 --&gt; IRQ arrives here and irq handler tries to modify uninitialized timer

    which triggers BUG_ON(!timer-&gt;function) in __mod_timer().

 Call Trace:
   &lt;IRQ&gt;
   [&lt;ffffffffa0532617&gt;] start_new_msg+0x47/0x80 [ipmi_si]
   [&lt;ffffffffa053269e&gt;] start_check_enables+0x4e/0x60 [ipmi_si]
   [&lt;ffffffffa0532bd8&gt;] smi_event_handler+0x1e8/0x640 [ipmi_si]
   [&lt;ffffffff810f5584&gt;] ? __rcu_process_callbacks+0x54/0x350
   [&lt;ffffffffa053327c&gt;] si_irq_handler+0x3c/0x60 [ipmi_si]
   [&lt;ffffffff810efaf0&gt;] handle_IRQ_event+0x60/0x170
   [&lt;ffffffff810f245e&gt;] handle_edge_irq+0xde/0x180
   [&lt;ffffffff8100fc59&gt;] handle_irq+0x49/0xa0
   [&lt;ffffffff8154643c&gt;] do_IRQ+0x6c/0xf0
   [&lt;ffffffff8100ba53&gt;] ret_from_intr+0x0/0x11

        /* Set up the timer that drives the interface. */
        setup_timer(&amp;new_smi-&gt;si_timer, smi_timeout, (long)new_smi);

The following patch fixes the problem.

To: Openipmi-developer@lists.sourceforge.net
To: Corey Minyard &lt;minyard@acm.org&gt;
CC: linux-kernel@vger.kernel.org

Signed-off-by: Jan Stancek &lt;jstancek@redhat.com&gt;
Signed-off-by: Tony Camuso &lt;tcamuso@redhat.com&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ipmi: Start the timer and thread on internal msgs</title>
<updated>2016-01-31T19:23:31+00:00</updated>
<author>
<name>Corey Minyard</name>
<email>cminyard@mvista.com</email>
</author>
<published>2015-09-05T22:44:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8dfca273353b9131dfd82c2720ccd78f89fd44ae'/>
<id>8dfca273353b9131dfd82c2720ccd78f89fd44ae</id>
<content type='text'>
commit 0cfec916e86d881e209de4b4ae9959a6271e6660 upstream.

The timer and thread were not being started for internal messages,
so in interrupt mode if something hung the timer would never go
off and clean things up.  Factor out the internal message sending
and start the timer for those messages, too.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
Tested-by: Gouji, Masayuki &lt;gouji.masayuki@jp.fujitsu.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0cfec916e86d881e209de4b4ae9959a6271e6660 upstream.

The timer and thread were not being started for internal messages,
so in interrupt mode if something hung the timer would never go
off and clean things up.  Factor out the internal message sending
and start the timer for those messages, too.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
Tested-by: Gouji, Masayuki &lt;gouji.masayuki@jp.fujitsu.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ipmi: Fix multi-part message handling</title>
<updated>2015-05-06T00:37:22+00:00</updated>
<author>
<name>Corey Minyard</name>
<email>cminyard@mvista.com</email>
</author>
<published>2015-04-29T22:59:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3d69d43baa2749c3d187ce70940d7aebe609e149'/>
<id>3d69d43baa2749c3d187ce70940d7aebe609e149</id>
<content type='text'>
Lots of little fixes for multi-part messages:

The values was not being re-initialized, if something went wrong
handling a multi-part message and it got left in a bad state, it
might be an issue.

The commands were not correct when issuing multi-part reads, the
code was not passing in the proper value for commands.  Also clean
up some minor formatting issues.

Get the block number from the right location, limit the maximum send
message size to 63 bytes and explain why, and fix some minor sylistic
issues.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Lots of little fixes for multi-part messages:

The values was not being re-initialized, if something went wrong
handling a multi-part message and it got left in a bad state, it
might be an issue.

The commands were not correct when issuing multi-part reads, the
code was not passing in the proper value for commands.  Also clean
up some minor formatting issues.

Get the block number from the right location, limit the maximum send
message size to 63 bytes and explain why, and fix some minor sylistic
issues.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipmi: Add alert handling to SSIF</title>
<updated>2015-05-06T00:36:38+00:00</updated>
<author>
<name>Corey Minyard</name>
<email>cminyard@mvista.com</email>
</author>
<published>2015-04-24T12:46:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9162052173d2381e2bbabc224c3c1457acb4c54c'/>
<id>9162052173d2381e2bbabc224c3c1457acb4c54c</id>
<content type='text'>
The SSIF interface can optionally have an SMBus alert come in when
data is ready.  Unfortunately, the IPMI spec gives wiggle room to
the implementer to allow them to always have the alert enabled,
even if the driver doesn't enable it.  So implement alerts.
If you don't in this situation, the SMBus alert handling will
constantly complain.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The SSIF interface can optionally have an SMBus alert come in when
data is ready.  Unfortunately, the IPMI spec gives wiggle room to
the implementer to allow them to always have the alert enabled,
even if the driver doesn't enable it.  So implement alerts.
If you don't in this situation, the SMBus alert handling will
constantly complain.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipmi: Fix a problem that messages are not issued in run_to_completion mode</title>
<updated>2015-05-06T00:33:49+00:00</updated>
<author>
<name>Hidehiro Kawai</name>
<email>hidehiro.kawai.ez@hitachi.com</email>
</author>
<published>2015-04-23T02:16:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9f8127048ab8b47b43f8aeaaec9fec2da44be9a1'/>
<id>9f8127048ab8b47b43f8aeaaec9fec2da44be9a1</id>
<content type='text'>
start_next_msg() issues a message placed in smi_info-&gt;waiting_msg
if it is non-NULL.  However, sender() sets a message to
smi_info-&gt;curr_msg and NULL to smi_info-&gt;waiting_msg in the context
of run_to_completion mode.  As the result, it leads an infinite
loop by waiting the completion of unissued message when leaving
dying message after kernel panic.

sender() should set the message to smi_info-&gt;waiting_msg not
curr_msg.

Signed-off-by: Hidehiro Kawai &lt;hidehiro.kawai.ez@hitachi.com&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
start_next_msg() issues a message placed in smi_info-&gt;waiting_msg
if it is non-NULL.  However, sender() sets a message to
smi_info-&gt;curr_msg and NULL to smi_info-&gt;waiting_msg in the context
of run_to_completion mode.  As the result, it leads an infinite
loop by waiting the completion of unissued message when leaving
dying message after kernel panic.

sender() should set the message to smi_info-&gt;waiting_msg not
curr_msg.

Signed-off-by: Hidehiro Kawai &lt;hidehiro.kawai.ez@hitachi.com&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipmi: Report an error if ACPI _IFT doesn't exist</title>
<updated>2015-05-06T00:33:48+00:00</updated>
<author>
<name>Corey Minyard</name>
<email>cminyard@mvista.com</email>
</author>
<published>2015-04-22T18:25:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a182a4b2b3e85a559ea2cd3545f4311db41325f2'/>
<id>a182a4b2b3e85a559ea2cd3545f4311db41325f2</id>
<content type='text'>
When probing an ACPI table, report a specific error, instead of just
returning an error, if _IFT doesn't exist.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When probing an ACPI table, report a specific error, instead of just
returning an error, if _IFT doesn't exist.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipmi: Remove unused including &lt;linux/version.h&gt;</title>
<updated>2015-05-06T00:33:28+00:00</updated>
<author>
<name>Wei Yongjun</name>
<email>yongjun_wei@trendmicro.com.cn</email>
</author>
<published>2015-04-16T13:09:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=15c5725e6b86cb8dfc4ca655a22005cc678a6f6f'/>
<id>15c5725e6b86cb8dfc4ca655a22005cc678a6f6f</id>
<content type='text'>
Remove including &lt;linux/version.h&gt; that don't need it.

Signed-off-by: Wei Yongjun &lt;yongjun_wei@trendmicro.com.cn&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove including &lt;linux/version.h&gt; that don't need it.

Signed-off-by: Wei Yongjun &lt;yongjun_wei@trendmicro.com.cn&gt;
Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ipmi: Don't report err in the SI driver for SSIF devices</title>
<updated>2015-05-05T19:24:46+00:00</updated>
<author>
<name>Corey Minyard</name>
<email>cminyard@mvista.com</email>
</author>
<published>2015-04-11T01:19:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b1e65e71535aa128089d4cb1b6d90db7551fcb05'/>
<id>b1e65e71535aa128089d4cb1b6d90db7551fcb05</id>
<content type='text'>
Really ignore them by returning -ENODEV from the probe, but not
doing anything.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Really ignore them by returning -ENODEV from the probe, but not
doing anything.

Signed-off-by: Corey Minyard &lt;cminyard@mvista.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
