<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net/ethernet/intel, branch linux-3.14.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>e1000: add dummy allocator to fix race condition between mtu change and netpoll</title>
<updated>2015-05-06T19:59:20+00:00</updated>
<author>
<name>Sabrina Dubroca</name>
<email>sd@queasysnail.net</email>
</author>
<published>2015-02-26T05:35:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=acc9faa606dad2ab85757e7698a3446179ed8154'/>
<id>acc9faa606dad2ab85757e7698a3446179ed8154</id>
<content type='text'>
commit 08e8331654d1d7b2c58045e549005bc356aa7810 upstream.

There is a race condition between e1000_change_mtu's cleanups and
netpoll, when we change the MTU across jumbo size:

Changing MTU frees all the rx buffers:
    e1000_change_mtu -&gt; e1000_down -&gt; e1000_clean_all_rx_rings -&gt;
        e1000_clean_rx_ring

Then, close to the end of e1000_change_mtu:
    pr_info -&gt; ... -&gt; netpoll_poll_dev -&gt; e1000_clean -&gt;
        e1000_clean_rx_irq -&gt; e1000_alloc_rx_buffers -&gt; e1000_alloc_frag

And when we come back to do the rest of the MTU change:
    e1000_up -&gt; e1000_configure -&gt; e1000_configure_rx -&gt;
        e1000_alloc_jumbo_rx_buffers

alloc_jumbo finds the buffers already != NULL, since data (shared with
page in e1000_rx_buffer-&gt;rxbuf) has been re-alloc'd, but it's garbage,
or at least not what is expected when in jumbo state.

This results in an unusable adapter (packets don't get through), and a
NULL pointer dereference on the next call to e1000_clean_rx_ring
(other mtu change, link down, shutdown):

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [&lt;ffffffff81194d6e&gt;] put_compound_page+0x7e/0x330

    [...]

Call Trace:
 [&lt;ffffffff81195445&gt;] put_page+0x55/0x60
 [&lt;ffffffff815d9f44&gt;] e1000_clean_rx_ring+0x134/0x200
 [&lt;ffffffff815da055&gt;] e1000_clean_all_rx_rings+0x45/0x60
 [&lt;ffffffff815df5e0&gt;] e1000_down+0x1c0/0x1d0
 [&lt;ffffffff811e2260&gt;] ? deactivate_slab+0x7f0/0x840
 [&lt;ffffffff815e21bc&gt;] e1000_change_mtu+0xdc/0x170
 [&lt;ffffffff81647050&gt;] dev_set_mtu+0xa0/0x140
 [&lt;ffffffff81664218&gt;] do_setlink+0x218/0xac0
 [&lt;ffffffff814459e9&gt;] ? nla_parse+0xb9/0x120
 [&lt;ffffffff816652d0&gt;] rtnl_newlink+0x6d0/0x890
 [&lt;ffffffff8104f000&gt;] ? kvm_clock_read+0x20/0x40
 [&lt;ffffffff810a2068&gt;] ? sched_clock_cpu+0xa8/0x100
 [&lt;ffffffff81663802&gt;] rtnetlink_rcv_msg+0x92/0x260

By setting the allocator to a dummy version, netpoll can't mess up our
rx buffers.  The allocator is set back to a sane value in
e1000_configure_rx.

Fixes: edbbb3ca1077 ("e1000: implement jumbo receive with partial descriptors")
Signed-off-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.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 08e8331654d1d7b2c58045e549005bc356aa7810 upstream.

There is a race condition between e1000_change_mtu's cleanups and
netpoll, when we change the MTU across jumbo size:

Changing MTU frees all the rx buffers:
    e1000_change_mtu -&gt; e1000_down -&gt; e1000_clean_all_rx_rings -&gt;
        e1000_clean_rx_ring

Then, close to the end of e1000_change_mtu:
    pr_info -&gt; ... -&gt; netpoll_poll_dev -&gt; e1000_clean -&gt;
        e1000_clean_rx_irq -&gt; e1000_alloc_rx_buffers -&gt; e1000_alloc_frag

And when we come back to do the rest of the MTU change:
    e1000_up -&gt; e1000_configure -&gt; e1000_configure_rx -&gt;
        e1000_alloc_jumbo_rx_buffers

alloc_jumbo finds the buffers already != NULL, since data (shared with
page in e1000_rx_buffer-&gt;rxbuf) has been re-alloc'd, but it's garbage,
or at least not what is expected when in jumbo state.

This results in an unusable adapter (packets don't get through), and a
NULL pointer dereference on the next call to e1000_clean_rx_ring
(other mtu change, link down, shutdown):

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [&lt;ffffffff81194d6e&gt;] put_compound_page+0x7e/0x330

    [...]

Call Trace:
 [&lt;ffffffff81195445&gt;] put_page+0x55/0x60
 [&lt;ffffffff815d9f44&gt;] e1000_clean_rx_ring+0x134/0x200
 [&lt;ffffffff815da055&gt;] e1000_clean_all_rx_rings+0x45/0x60
 [&lt;ffffffff815df5e0&gt;] e1000_down+0x1c0/0x1d0
 [&lt;ffffffff811e2260&gt;] ? deactivate_slab+0x7f0/0x840
 [&lt;ffffffff815e21bc&gt;] e1000_change_mtu+0xdc/0x170
 [&lt;ffffffff81647050&gt;] dev_set_mtu+0xa0/0x140
 [&lt;ffffffff81664218&gt;] do_setlink+0x218/0xac0
 [&lt;ffffffff814459e9&gt;] ? nla_parse+0xb9/0x120
 [&lt;ffffffff816652d0&gt;] rtnl_newlink+0x6d0/0x890
 [&lt;ffffffff8104f000&gt;] ? kvm_clock_read+0x20/0x40
 [&lt;ffffffff810a2068&gt;] ? sched_clock_cpu+0xa8/0x100
 [&lt;ffffffff81663802&gt;] rtnetlink_rcv_msg+0x92/0x260

By setting the allocator to a dummy version, netpoll can't mess up our
rx buffers.  The allocator is set back to a sane value in
e1000_configure_rx.

Fixes: edbbb3ca1077 ("e1000: implement jumbo receive with partial descriptors")
Signed-off-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ixgb: Call dev_kfree_skby_any instead of dev_kfree_skb.</title>
<updated>2015-04-29T08:31:48+00:00</updated>
<author>
<name>Eric W. Biederman</name>
<email>ebiederm@xmission.com</email>
</author>
<published>2014-03-11T21:18:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3a7070f0ac7b1a18f62f8569a93c8b927c3f5118'/>
<id>3a7070f0ac7b1a18f62f8569a93c8b927c3f5118</id>
<content type='text'>
Replace dev_kfree_skb with dev_kfree_skb_any in functions that can
be called in hard irq and other contexts.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&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>
Replace dev_kfree_skb with dev_kfree_skb_any in functions that can
be called in hard irq and other contexts.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>igb: bring link up when PHY is powered up</title>
<updated>2014-12-16T17:34:28+00:00</updated>
<author>
<name>Todd Fujinaka</name>
<email>todd.fujinaka@intel.com</email>
</author>
<published>2014-06-17T06:58:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7d4a6dae27501820b234c81dc178901cddfceeda'/>
<id>7d4a6dae27501820b234c81dc178901cddfceeda</id>
<content type='text'>
commit aec653c43b0c55667355e26d7de1236bda9fb4e3 upstream.

Call igb_setup_link() when the PHY is powered up.

Signed-off-by: Todd Fujinaka &lt;todd.fujinaka@intel.com&gt;
Reported-by: Jeff Westfahl &lt;jeff.westfahl@ni.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Cc: Vincent Donnefort &lt;vdonnefort@gmail.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 aec653c43b0c55667355e26d7de1236bda9fb4e3 upstream.

Call igb_setup_link() when the PHY is powered up.

Signed-off-by: Todd Fujinaka &lt;todd.fujinaka@intel.com&gt;
Reported-by: Jeff Westfahl &lt;jeff.westfahl@ni.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Cc: Vincent Donnefort &lt;vdonnefort@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>i40e: Don't stop driver probe when querying DCB config fails</title>
<updated>2014-10-15T06:36:40+00:00</updated>
<author>
<name>Neerav Parikh</name>
<email>neerav.parikh@intel.com</email>
</author>
<published>2014-08-13T11:30:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=46b6abb9241bbb077cd397cfa1326540b978044f'/>
<id>46b6abb9241bbb077cd397cfa1326540b978044f</id>
<content type='text'>
Commit id: 014269ff376f552363ecdab78d3d947fbe2237d9 in Linus's tree
should be queued up for stable 3.14 &amp; 3.15 since the i40e driver will
not load when DCB is enabled, unless this patch is applied.

In case of any AQ command to query port's DCB configuration fails
during driver's probe time; the probe fails and returns an error.

This patch prevents this issue by continuing the driver probe even
when an error is returned.

Also, added an error message to dump the AQ error status to show what
error caused the failure to get the DCB configuration from firmware.

Change-ID: Ifd5663512588bca684069bb7d4fb586dd72221af
Signed-off-by: Neerav Parikh &lt;neerav.parikh@intel.com&gt;
Signed-off-by: Catherine Sullivan &lt;catherine.sullivan@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.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 id: 014269ff376f552363ecdab78d3d947fbe2237d9 in Linus's tree
should be queued up for stable 3.14 &amp; 3.15 since the i40e driver will
not load when DCB is enabled, unless this patch is applied.

In case of any AQ command to query port's DCB configuration fails
during driver's probe time; the probe fails and returns an error.

This patch prevents this issue by continuing the driver probe even
when an error is returned.

Also, added an error message to dump the AQ error status to show what
error caused the failure to get the DCB configuration from firmware.

Change-ID: Ifd5663512588bca684069bb7d4fb586dd72221af
Signed-off-by: Neerav Parikh &lt;neerav.parikh@intel.com&gt;
Signed-off-by: Catherine Sullivan &lt;catherine.sullivan@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>e1000e: Fix SHRA register access for 82579</title>
<updated>2014-07-28T15:05:58+00:00</updated>
<author>
<name>David Ertman</name>
<email>davidx.m.ertman@intel.com</email>
</author>
<published>2014-03-05T07:50:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8d114c86d88ee7dc52760b585f4abdf358fabca1'/>
<id>8d114c86d88ee7dc52760b585f4abdf358fabca1</id>
<content type='text'>
commit 96dee024ca4799d6d21588951240035c21ba1c67 upstream.

Previous commit c3a0dce35af0 fixed an overrun for the RAR on i218 devices.
This commit also attempted to homogenize the RAR/SHRA access for all parts
accessed by the e1000e driver.  This change introduced an error for
assigning MAC addresses to guest OS's for 82579 devices.

Only RAR[0] is accessible to the driver for 82579 parts, and additional
addresses must be placed into the SHRA[L|H] registers.  The rar_entry_count
was changed in the previous commit to an inaccurate value that accounted
for all RAR and SHRA registers, not just the ones usable by the driver.

This patch fixes the count to the correct value and adjusts the
e1000_rar_set_pch2lan() function to user the correct index.

Cc: John Greene &lt;jogreene@redhat.com&gt;
Signed-off-by: Dave Ertman &lt;davidx.m.ertman@intel.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Cc: "Alexander Y. Fomichev" &lt;aleksandr.fomichev@x5.ru&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 96dee024ca4799d6d21588951240035c21ba1c67 upstream.

Previous commit c3a0dce35af0 fixed an overrun for the RAR on i218 devices.
This commit also attempted to homogenize the RAR/SHRA access for all parts
accessed by the e1000e driver.  This change introduced an error for
assigning MAC addresses to guest OS's for 82579 devices.

Only RAR[0] is accessible to the driver for 82579 parts, and additional
addresses must be placed into the SHRA[L|H] registers.  The rar_entry_count
was changed in the previous commit to an inaccurate value that accounted
for all RAR and SHRA registers, not just the ones usable by the driver.

This patch fixes the count to the correct value and adjusts the
e1000_rar_set_pch2lan() function to user the correct index.

Cc: John Greene &lt;jogreene@redhat.com&gt;
Signed-off-by: Dave Ertman &lt;davidx.m.ertman@intel.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Cc: "Alexander Y. Fomichev" &lt;aleksandr.fomichev@x5.ru&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>igb: do a reset on SR-IOV re-init if device is down</title>
<updated>2014-07-28T15:05:58+00:00</updated>
<author>
<name>Stefan Assmann</name>
<email>sassmann@kpanic.de</email>
</author>
<published>2014-07-10T10:29:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f09e424e436c56fd8c4ebd182d407851b7f42d83'/>
<id>f09e424e436c56fd8c4ebd182d407851b7f42d83</id>
<content type='text'>
commit 76252723e88681628a3dbb9c09c963e095476f73 upstream.

To properly re-initialize SR-IOV it is necessary to reset the device
even if it is already down. Not doing this may result in Tx unit hangs.

Signed-off-by: Stefan Assmann &lt;sassmann@kpanic.de&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&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 76252723e88681628a3dbb9c09c963e095476f73 upstream.

To properly re-initialize SR-IOV it is necessary to reset the device
even if it is already down. Not doing this may result in Tx unit hangs.

Signed-off-by: Stefan Assmann &lt;sassmann@kpanic.de&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>igb: Workaround for i210 Errata 25: Slow System Clock</title>
<updated>2014-07-28T15:05:57+00:00</updated>
<author>
<name>Todd Fujinaka</name>
<email>todd.fujinaka@intel.com</email>
</author>
<published>2014-07-10T08:47:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=081caead26b5841c597d520be8ff1e2f69b4fadc'/>
<id>081caead26b5841c597d520be8ff1e2f69b4fadc</id>
<content type='text'>
commit 948264879b6894dc389a44b99fae4f0b72932619 upstream.

On some devices, the internal PLL circuit occasionally provides the
wrong clock frequency after power up. The probability of failure is less
than one failure per 1000 power cycles. When the failure occurs, the
internal clock frequency is around 1/20 of the correct frequency.

Signed-off-by: Todd Fujinaka &lt;todd.fujinaka@intel.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&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 948264879b6894dc389a44b99fae4f0b72932619 upstream.

On some devices, the internal PLL circuit occasionally provides the
wrong clock frequency after power up. The probability of failure is less
than one failure per 1000 power cycles. When the failure occurs, the
internal clock frequency is around 1/20 of the correct frequency.

Signed-off-by: Todd Fujinaka &lt;todd.fujinaka@intel.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>e1000e: Fix no connectivity when driver loaded with cable out</title>
<updated>2014-06-07T17:28:20+00:00</updated>
<author>
<name>David Ertman</name>
<email>davidx.m.ertman@intel.com</email>
</author>
<published>2014-03-25T04:27:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a23e2fa7ab52dfec62dc40de5cea10aec7cacdda'/>
<id>a23e2fa7ab52dfec62dc40de5cea10aec7cacdda</id>
<content type='text'>
commit b20a774495671f037e7160ea2ce8789af6b61533 upstream.

In commit da1e2046e5, the flow for enabling/disabling an Si errata
workaround (e1000_lv_jumbo_workaround_ich8lan) was changed to fix a problem
with iAMT connections dropping on interface down with jumbo frames set.
Part of this change was to move the function call disabling the workaround
to e1000e_down() from the e1000_setup_rctl() function.  The mechanic for
disabling of this workaround involves writing several MAC and PHY registers
back to hardware defaults.

After this commit, when the driver is loaded with the cable out, the PHY
registers are not programmed with the correct default values.  This causes
the device to be capable of transmitting packets, but is unable to recieve
them until this workaround is called.

The flow of e1000e's open code relies upon calling the above workaround to
expicitly program these registers either with jumbo frame appropriate settings
or h/w defaults on 82579 and newer hardware.

Fix this issue by adding logic to e1000_setup_rctl() that not only calls
e1000_lv_jumbo_workaround_ich8lan() when jumbo frames are set, to enable the
workaround, but also calls this function to explicitly disable the workaround
in the case that jumbo frames are not set.

Signed-off-by: Dave Ertman &lt;davidx.m.ertman@intel.com&gt;
Tested-by: Jeff Pieper &lt;jeffrey.e.pieper@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&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 b20a774495671f037e7160ea2ce8789af6b61533 upstream.

In commit da1e2046e5, the flow for enabling/disabling an Si errata
workaround (e1000_lv_jumbo_workaround_ich8lan) was changed to fix a problem
with iAMT connections dropping on interface down with jumbo frames set.
Part of this change was to move the function call disabling the workaround
to e1000e_down() from the e1000_setup_rctl() function.  The mechanic for
disabling of this workaround involves writing several MAC and PHY registers
back to hardware defaults.

After this commit, when the driver is loaded with the cable out, the PHY
registers are not programmed with the correct default values.  This causes
the device to be capable of transmitting packets, but is unable to recieve
them until this workaround is called.

The flow of e1000e's open code relies upon calling the above workaround to
expicitly program these registers either with jumbo frame appropriate settings
or h/w defaults on 82579 and newer hardware.

Fix this issue by adding logic to e1000_setup_rctl() that not only calls
e1000_lv_jumbo_workaround_ich8lan() when jumbo frames are set, to enable the
workaround, but also calls this function to explicitly disable the workaround
in the case that jumbo frames are not set.

Signed-off-by: Dave Ertman &lt;davidx.m.ertman@intel.com&gt;
Tested-by: Jeff Pieper &lt;jeffrey.e.pieper@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>igb: Unset IGB_FLAG_HAS_MSIX-flag when falling back to msi-only</title>
<updated>2014-06-07T17:28:18+00:00</updated>
<author>
<name>Christoph Paasch</name>
<email>christoph.paasch@uclouvain.be</email>
</author>
<published>2014-03-21T11:02:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4fe6be724f7045fd6ecf59941b4f94fdd50f82b8'/>
<id>4fe6be724f7045fd6ecf59941b4f94fdd50f82b8</id>
<content type='text'>
commit b709323d2477614823a38c2f2a9a206e087e28fc upstream.

Prior to cd14ef54d25 (igb: Change to use statically allocated array for
MSIx entries), having msix_entries different from NULL was an indicator
that MSIX is enabled.
In igb_set_interrupt_capabiliy we may fall back to MSI-only. Prior to
the above patch msix_entries was set to NULL by
igb_reset_interrupt_capability.

However, now we are checking the flag for IGB_FLAG_HAS_MSIX and so the
stack gets completly confused:

[   42.659791] ------------[ cut here ]------------
[   42.715032] WARNING: CPU: 7 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x15c/0x1fb()
[   42.848263] NETDEV WATCHDOG: eth0 (igb): transmit queue 0 timed out
[   42.923253] Modules linked in:
[   42.959875] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.14.0-rc2-mptcp #437
[   43.043184] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011
[   43.119215]  0000000000000108 ffff88023fdc3da8 ffffffff81487847 0000000000000108
[   43.208165]  ffff88023fdc3df8 ffff88023fdc3de8 ffffffff81034e7d ffff88023fdc3dd8
[   43.297120]  ffffffff813fff10 ffff880236018000 ffff880236b178c0 0000000000000008
[   43.386071] Call Trace:
[   43.415303]  &lt;IRQ&gt;  [&lt;ffffffff81487847&gt;] dump_stack+0x49/0x62
[   43.484174]  [&lt;ffffffff81034e7d&gt;] warn_slowpath_common+0x77/0x91
[   43.556049]  [&lt;ffffffff813fff10&gt;] ? dev_watchdog+0x15c/0x1fb
[   43.623759]  [&lt;ffffffff81034f2b&gt;] warn_slowpath_fmt+0x41/0x43
[   43.692511]  [&lt;ffffffff813fff10&gt;] dev_watchdog+0x15c/0x1fb
[   43.758141]  [&lt;ffffffff813ffdb4&gt;] ? __netdev_watchdog_up+0x64/0x64
[   43.832091]  [&lt;ffffffff8103cd04&gt;] call_timer_fn+0x17/0x6f
[   43.896682]  [&lt;ffffffff8103cebe&gt;] run_timer_softirq+0x162/0x1a2
[   43.967511]  [&lt;ffffffff81038520&gt;] __do_softirq+0xcd/0x1cc
[   44.032104]  [&lt;ffffffff81038689&gt;] irq_exit+0x3a/0x48
[   44.091492]  [&lt;ffffffff81026d43&gt;] smp_apic_timer_interrupt+0x43/0x50
[   44.167525]  [&lt;ffffffff8148c24a&gt;] apic_timer_interrupt+0x6a/0x70
[   44.239392]  &lt;EOI&gt;  [&lt;ffffffff8100992c&gt;] ? default_idle+0x6/0x8
[   44.310343]  [&lt;ffffffff81009b31&gt;] arch_cpu_idle+0x13/0x18
[   44.374934]  [&lt;ffffffff81066126&gt;] cpu_startup_entry+0xa7/0x101
[   44.444724]  [&lt;ffffffff81025660&gt;] start_secondary+0x1b2/0x1b7
[   44.513472] ---[ end trace a5a075fd4e7f854f ]---
[   44.568753] igb 0000:04:00.0 eth0: Reset adapter
[   46.206945] random: nonblocking pool is initialized
[   46.465670] irq 44: nobody cared (try booting with the "irqpoll" option)
[   46.545862] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G        W    3.14.0-rc2-mptcp #437
[   46.640610] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011
[   46.716641]  ffff8802363f8c84 ffff88023fdc3e38 ffffffff81487847 00000000a03cdb6d
[   46.805598]  ffff8802363f8c00 ffff88023fdc3e68 ffffffff81068489 0000007f81825400
[   46.894539]  ffff8802363f8c00 0000000000000000 0000000000000000 ffff88023fdc3ea8
[   46.983484] Call Trace:
[   47.012714]  &lt;IRQ&gt;  [&lt;ffffffff81487847&gt;] dump_stack+0x49/0x62
[   47.081585]  [&lt;ffffffff81068489&gt;] __report_bad_irq+0x35/0xc1
[   47.149295]  [&lt;ffffffff81068683&gt;] note_interrupt+0x16e/0x1ea
[   47.217006]  [&lt;ffffffff8106679e&gt;] handle_irq_event_percpu+0x116/0x12e
[   47.294075]  [&lt;ffffffff810667e9&gt;] handle_irq_event+0x33/0x4f
[   47.361787]  [&lt;ffffffff81068c95&gt;] handle_fasteoi_irq+0x83/0xd1
[   47.431577]  [&lt;ffffffff81003d5b&gt;] handle_irq+0x1f/0x28
[   47.493047]  [&lt;ffffffff81003567&gt;] do_IRQ+0x4e/0xd4
[   47.550358]  [&lt;ffffffff8148b06a&gt;] common_interrupt+0x6a/0x6a
[   47.618066]  &lt;EOI&gt;  [&lt;ffffffff8100992c&gt;] ? default_idle+0x6/0x8
[   47.689016]  [&lt;ffffffff81009b31&gt;] arch_cpu_idle+0x13/0x18
[   47.753605]  [&lt;ffffffff81066126&gt;] cpu_startup_entry+0xa7/0x101
[   47.823397]  [&lt;ffffffff81025660&gt;] start_secondary+0x1b2/0x1b7
[   47.892146] handlers:
[   47.919301] [&lt;ffffffff812fbd7d&gt;] igb_intr

So, this patch unsets the flag to indicate that we are not using MSIX.
This patch does exactly this: Unsetting the flag when falling back to MSI.

Fixes: cd14ef54d25b (igb: Change to use statically allocated array for MSIx entries)
Cc: Carolyn Wyborny &lt;carolyn.wyborny@intel.com&gt;
Signed-off-by: Christoph Paasch &lt;christoph.paasch@uclouvain.be&gt;
Tested-by: Jeff Pieper &lt;jeffrey.e.pieper@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.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 b709323d2477614823a38c2f2a9a206e087e28fc upstream.

Prior to cd14ef54d25 (igb: Change to use statically allocated array for
MSIx entries), having msix_entries different from NULL was an indicator
that MSIX is enabled.
In igb_set_interrupt_capabiliy we may fall back to MSI-only. Prior to
the above patch msix_entries was set to NULL by
igb_reset_interrupt_capability.

However, now we are checking the flag for IGB_FLAG_HAS_MSIX and so the
stack gets completly confused:

[   42.659791] ------------[ cut here ]------------
[   42.715032] WARNING: CPU: 7 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x15c/0x1fb()
[   42.848263] NETDEV WATCHDOG: eth0 (igb): transmit queue 0 timed out
[   42.923253] Modules linked in:
[   42.959875] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.14.0-rc2-mptcp #437
[   43.043184] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011
[   43.119215]  0000000000000108 ffff88023fdc3da8 ffffffff81487847 0000000000000108
[   43.208165]  ffff88023fdc3df8 ffff88023fdc3de8 ffffffff81034e7d ffff88023fdc3dd8
[   43.297120]  ffffffff813fff10 ffff880236018000 ffff880236b178c0 0000000000000008
[   43.386071] Call Trace:
[   43.415303]  &lt;IRQ&gt;  [&lt;ffffffff81487847&gt;] dump_stack+0x49/0x62
[   43.484174]  [&lt;ffffffff81034e7d&gt;] warn_slowpath_common+0x77/0x91
[   43.556049]  [&lt;ffffffff813fff10&gt;] ? dev_watchdog+0x15c/0x1fb
[   43.623759]  [&lt;ffffffff81034f2b&gt;] warn_slowpath_fmt+0x41/0x43
[   43.692511]  [&lt;ffffffff813fff10&gt;] dev_watchdog+0x15c/0x1fb
[   43.758141]  [&lt;ffffffff813ffdb4&gt;] ? __netdev_watchdog_up+0x64/0x64
[   43.832091]  [&lt;ffffffff8103cd04&gt;] call_timer_fn+0x17/0x6f
[   43.896682]  [&lt;ffffffff8103cebe&gt;] run_timer_softirq+0x162/0x1a2
[   43.967511]  [&lt;ffffffff81038520&gt;] __do_softirq+0xcd/0x1cc
[   44.032104]  [&lt;ffffffff81038689&gt;] irq_exit+0x3a/0x48
[   44.091492]  [&lt;ffffffff81026d43&gt;] smp_apic_timer_interrupt+0x43/0x50
[   44.167525]  [&lt;ffffffff8148c24a&gt;] apic_timer_interrupt+0x6a/0x70
[   44.239392]  &lt;EOI&gt;  [&lt;ffffffff8100992c&gt;] ? default_idle+0x6/0x8
[   44.310343]  [&lt;ffffffff81009b31&gt;] arch_cpu_idle+0x13/0x18
[   44.374934]  [&lt;ffffffff81066126&gt;] cpu_startup_entry+0xa7/0x101
[   44.444724]  [&lt;ffffffff81025660&gt;] start_secondary+0x1b2/0x1b7
[   44.513472] ---[ end trace a5a075fd4e7f854f ]---
[   44.568753] igb 0000:04:00.0 eth0: Reset adapter
[   46.206945] random: nonblocking pool is initialized
[   46.465670] irq 44: nobody cared (try booting with the "irqpoll" option)
[   46.545862] CPU: 7 PID: 0 Comm: swapper/7 Tainted: G        W    3.14.0-rc2-mptcp #437
[   46.640610] Hardware name: HP ProLiant DL165 G7, BIOS O37 01/26/2011
[   46.716641]  ffff8802363f8c84 ffff88023fdc3e38 ffffffff81487847 00000000a03cdb6d
[   46.805598]  ffff8802363f8c00 ffff88023fdc3e68 ffffffff81068489 0000007f81825400
[   46.894539]  ffff8802363f8c00 0000000000000000 0000000000000000 ffff88023fdc3ea8
[   46.983484] Call Trace:
[   47.012714]  &lt;IRQ&gt;  [&lt;ffffffff81487847&gt;] dump_stack+0x49/0x62
[   47.081585]  [&lt;ffffffff81068489&gt;] __report_bad_irq+0x35/0xc1
[   47.149295]  [&lt;ffffffff81068683&gt;] note_interrupt+0x16e/0x1ea
[   47.217006]  [&lt;ffffffff8106679e&gt;] handle_irq_event_percpu+0x116/0x12e
[   47.294075]  [&lt;ffffffff810667e9&gt;] handle_irq_event+0x33/0x4f
[   47.361787]  [&lt;ffffffff81068c95&gt;] handle_fasteoi_irq+0x83/0xd1
[   47.431577]  [&lt;ffffffff81003d5b&gt;] handle_irq+0x1f/0x28
[   47.493047]  [&lt;ffffffff81003567&gt;] do_IRQ+0x4e/0xd4
[   47.550358]  [&lt;ffffffff8148b06a&gt;] common_interrupt+0x6a/0x6a
[   47.618066]  &lt;EOI&gt;  [&lt;ffffffff8100992c&gt;] ? default_idle+0x6/0x8
[   47.689016]  [&lt;ffffffff81009b31&gt;] arch_cpu_idle+0x13/0x18
[   47.753605]  [&lt;ffffffff81066126&gt;] cpu_startup_entry+0xa7/0x101
[   47.823397]  [&lt;ffffffff81025660&gt;] start_secondary+0x1b2/0x1b7
[   47.892146] handlers:
[   47.919301] [&lt;ffffffff812fbd7d&gt;] igb_intr

So, this patch unsets the flag to indicate that we are not using MSIX.
This patch does exactly this: Unsetting the flag when falling back to MSI.

Fixes: cd14ef54d25b (igb: Change to use statically allocated array for MSIx entries)
Cc: Carolyn Wyborny &lt;carolyn.wyborny@intel.com&gt;
Signed-off-by: Christoph Paasch &lt;christoph.paasch@uclouvain.be&gt;
Tested-by: Jeff Pieper &lt;jeffrey.e.pieper@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>igb: Fix Null-pointer dereference in igb_reset_q_vector</title>
<updated>2014-06-07T17:28:18+00:00</updated>
<author>
<name>Christoph Paasch</name>
<email>christoph.paasch@uclouvain.be</email>
</author>
<published>2014-03-21T10:48:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5c0f1fdbaebb742c0903bba402772f0db7760aa1'/>
<id>5c0f1fdbaebb742c0903bba402772f0db7760aa1</id>
<content type='text'>
commit cb06d102327eadcd1bdc480bfd9f8876251d1007 upstream.

When igb_set_interrupt_capability() calls
igb_reset_interrupt_capability() (e.g., because CONFIG_PCI_MSI is unset),
num_q_vectors has been set but no vector has yet been allocated.

igb_reset_interrupt_capability() will then call igb_reset_q_vector,
which assumes that the vector is allocated. As this is not the case, we
are accessing a NULL-pointer.

This patch fixes it by checking that q_vector is indeed different from
NULL.

Fixes: 02ef6e1d0b0023 (igb: Fix queue allocation method to accommodate changing during runtime)
Cc: Carolyn Wyborny &lt;carolyn.wyborny@intel.com&gt;
Signed-off-by: Christoph Paasch &lt;christoph.paasch@uclouvain.be&gt;
Tested-by: Jeff Pieper &lt;jeffrey.e.pieper@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.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 cb06d102327eadcd1bdc480bfd9f8876251d1007 upstream.

When igb_set_interrupt_capability() calls
igb_reset_interrupt_capability() (e.g., because CONFIG_PCI_MSI is unset),
num_q_vectors has been set but no vector has yet been allocated.

igb_reset_interrupt_capability() will then call igb_reset_q_vector,
which assumes that the vector is allocated. As this is not the case, we
are accessing a NULL-pointer.

This patch fixes it by checking that q_vector is indeed different from
NULL.

Fixes: 02ef6e1d0b0023 (igb: Fix queue allocation method to accommodate changing during runtime)
Cc: Carolyn Wyborny &lt;carolyn.wyborny@intel.com&gt;
Signed-off-by: Christoph Paasch &lt;christoph.paasch@uclouvain.be&gt;
Tested-by: Jeff Pieper &lt;jeffrey.e.pieper@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
