<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net/ethernet/intel, branch v4.2.3</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>igb: Fix oops caused by missing queue pairing</title>
<updated>2015-09-29T17:33:17+00:00</updated>
<author>
<name>Shota Suzuki</name>
<email>suzuki_shota_t3@lab.ntt.co.jp</email>
</author>
<published>2015-07-01T00:25:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f4b7f93cd34a6153d454a837708fd4203990d1ae'/>
<id>f4b7f93cd34a6153d454a837708fd4203990d1ae</id>
<content type='text'>
commit 72ddef0506da852dc82f078f37ced8ef4d74a2bf upstream.

When initializing igb driver (e.g. 82576, I350), IGB_FLAG_QUEUE_PAIRS is
set if adapter-&gt;rss_queues exceeds half of max_rss_queues in
igb_init_queue_configuration().
On the other hand, IGB_FLAG_QUEUE_PAIRS is not set even if the number of
queues exceeds half of max_combined in igb_set_channels() when changing
the number of queues by "ethtool -L".
In this case, if numvecs is larger than MAX_MSIX_ENTRIES (10), the size
of adapter-&gt;msix_entries[], an overflow can occur in
igb_set_interrupt_capability(), which in turn leads to an oops.

Fix this problem as follows:
 - When changing the number of queues by "ethtool -L", set
   IGB_FLAG_QUEUE_PAIRS in the same way as initializing igb driver.
 - When increasing the size of q_vector, reallocate it appropriately.
   (With IGB_FLAG_QUEUE_PAIRS set, the size of q_vector gets larger.)

Another possible way to fix this problem is to cap the queues at its
initial number, which is the number of the initial online cpus. But this
is not the optimal way because we cannot increase queues when another
cpu becomes online.

Note that before commit cd14ef54d25b ("igb: Change to use statically
allocated array for MSIx entries"), this problem did not cause oops
but just made the number of queues become 1 because of entering msi_only
mode in igb_set_interrupt_capability().

Fixes: 907b7835799f ("igb: Add ethtool support to configure number of channels")
Signed-off-by: Shota Suzuki &lt;suzuki_shota_t3@lab.ntt.co.jp&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 72ddef0506da852dc82f078f37ced8ef4d74a2bf upstream.

When initializing igb driver (e.g. 82576, I350), IGB_FLAG_QUEUE_PAIRS is
set if adapter-&gt;rss_queues exceeds half of max_rss_queues in
igb_init_queue_configuration().
On the other hand, IGB_FLAG_QUEUE_PAIRS is not set even if the number of
queues exceeds half of max_combined in igb_set_channels() when changing
the number of queues by "ethtool -L".
In this case, if numvecs is larger than MAX_MSIX_ENTRIES (10), the size
of adapter-&gt;msix_entries[], an overflow can occur in
igb_set_interrupt_capability(), which in turn leads to an oops.

Fix this problem as follows:
 - When changing the number of queues by "ethtool -L", set
   IGB_FLAG_QUEUE_PAIRS in the same way as initializing igb driver.
 - When increasing the size of q_vector, reallocate it appropriately.
   (With IGB_FLAG_QUEUE_PAIRS set, the size of q_vector gets larger.)

Another possible way to fix this problem is to cap the queues at its
initial number, which is the number of the initial online cpus. But this
is not the optimal way because we cannot increase queues when another
cpu becomes online.

Note that before commit cd14ef54d25b ("igb: Change to use statically
allocated array for MSIx entries"), this problem did not cause oops
but just made the number of queues become 1 because of entering msi_only
mode in igb_set_interrupt_capability().

Fixes: 907b7835799f ("igb: Add ethtool support to configure number of channels")
Signed-off-by: Shota Suzuki &lt;suzuki_shota_t3@lab.ntt.co.jp&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>mm: make page pfmemalloc check more robust</title>
<updated>2015-08-21T21:30:10+00:00</updated>
<author>
<name>Michal Hocko</name>
<email>mhocko@suse.com</email>
</author>
<published>2015-08-21T21:11:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2f064f3485cd29633ad1b3cfb00cc519509a3d72'/>
<id>2f064f3485cd29633ad1b3cfb00cc519509a3d72</id>
<content type='text'>
Commit c48a11c7ad26 ("netvm: propagate page-&gt;pfmemalloc to skb") added
checks for page-&gt;pfmemalloc to __skb_fill_page_desc():

        if (page-&gt;pfmemalloc &amp;&amp; !page-&gt;mapping)
                skb-&gt;pfmemalloc = true;

It assumes page-&gt;mapping == NULL implies that page-&gt;pfmemalloc can be
trusted.  However, __delete_from_page_cache() can set set page-&gt;mapping
to NULL and leave page-&gt;index value alone.  Due to being in union, a
non-zero page-&gt;index will be interpreted as true page-&gt;pfmemalloc.

So the assumption is invalid if the networking code can see such a page.
And it seems it can.  We have encountered this with a NFS over loopback
setup when such a page is attached to a new skbuf.  There is no copying
going on in this case so the page confuses __skb_fill_page_desc which
interprets the index as pfmemalloc flag and the network stack drops
packets that have been allocated using the reserves unless they are to
be queued on sockets handling the swapping which is the case here and
that leads to hangs when the nfs client waits for a response from the
server which has been dropped and thus never arrive.

The struct page is already heavily packed so rather than finding another
hole to put it in, let's do a trick instead.  We can reuse the index
again but define it to an impossible value (-1UL).  This is the page
index so it should never see the value that large.  Replace all direct
users of page-&gt;pfmemalloc by page_is_pfmemalloc which will hide this
nastiness from unspoiled eyes.

The information will get lost if somebody wants to use page-&gt;index
obviously but that was the case before and the original code expected
that the information should be persisted somewhere else if that is
really needed (e.g.  what SLAB and SLUB do).

[akpm@linux-foundation.org: fix blooper in slub]
Fixes: c48a11c7ad26 ("netvm: propagate page-&gt;pfmemalloc to skb")
Signed-off-by: Michal Hocko &lt;mhocko@suse.com&gt;
Debugged-by: Vlastimil Babka &lt;vbabka@suse.com&gt;
Debugged-by: Jiri Bohac &lt;jbohac@suse.com&gt;
Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Cc: David Miller &lt;davem@davemloft.net&gt;
Acked-by: Mel Gorman &lt;mgorman@suse.de&gt;
Cc: &lt;stable@vger.kernel.org&gt;	[3.6+]
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;

Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit c48a11c7ad26 ("netvm: propagate page-&gt;pfmemalloc to skb") added
checks for page-&gt;pfmemalloc to __skb_fill_page_desc():

        if (page-&gt;pfmemalloc &amp;&amp; !page-&gt;mapping)
                skb-&gt;pfmemalloc = true;

It assumes page-&gt;mapping == NULL implies that page-&gt;pfmemalloc can be
trusted.  However, __delete_from_page_cache() can set set page-&gt;mapping
to NULL and leave page-&gt;index value alone.  Due to being in union, a
non-zero page-&gt;index will be interpreted as true page-&gt;pfmemalloc.

So the assumption is invalid if the networking code can see such a page.
And it seems it can.  We have encountered this with a NFS over loopback
setup when such a page is attached to a new skbuf.  There is no copying
going on in this case so the page confuses __skb_fill_page_desc which
interprets the index as pfmemalloc flag and the network stack drops
packets that have been allocated using the reserves unless they are to
be queued on sockets handling the swapping which is the case here and
that leads to hangs when the nfs client waits for a response from the
server which has been dropped and thus never arrive.

The struct page is already heavily packed so rather than finding another
hole to put it in, let's do a trick instead.  We can reuse the index
again but define it to an impossible value (-1UL).  This is the page
index so it should never see the value that large.  Replace all direct
users of page-&gt;pfmemalloc by page_is_pfmemalloc which will hide this
nastiness from unspoiled eyes.

The information will get lost if somebody wants to use page-&gt;index
obviously but that was the case before and the original code expected
that the information should be persisted somewhere else if that is
really needed (e.g.  what SLAB and SLUB do).

[akpm@linux-foundation.org: fix blooper in slub]
Fixes: c48a11c7ad26 ("netvm: propagate page-&gt;pfmemalloc to skb")
Signed-off-by: Michal Hocko &lt;mhocko@suse.com&gt;
Debugged-by: Vlastimil Babka &lt;vbabka@suse.com&gt;
Debugged-by: Jiri Bohac &lt;jbohac@suse.com&gt;
Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Cc: David Miller &lt;davem@davemloft.net&gt;
Acked-by: Mel Gorman &lt;mgorman@suse.de&gt;
Cc: &lt;stable@vger.kernel.org&gt;	[3.6+]
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;

Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i40evf: don't configure unused RSS queues</title>
<updated>2015-06-26T09:52:27+00:00</updated>
<author>
<name>Mitch Williams</name>
<email>mitch.a.williams@intel.com</email>
</author>
<published>2015-06-23T00:26:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=40746eb14c6b44f4d635c2f4cf8c67550db9b3ab'/>
<id>40746eb14c6b44f4d635c2f4cf8c67550db9b3ab</id>
<content type='text'>
The driver will only configure as many queues as there are available
CPUs, up the maximum number of queues. However, it always configures
RSS as though it is using the maximum number of queues. This can cause
the device to drop a lot of RX traffic, as the packets get assigned to
nonfunctional queues.

Fix this by only configuring RSS with the number of active queues.

Signed-off-by: Mitch Williams &lt;mitch.a.williams@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The driver will only configure as many queues as there are available
CPUs, up the maximum number of queues. However, it always configures
RSS as though it is using the maximum number of queues. This can cause
the device to drop a lot of RX traffic, as the packets get assigned to
nonfunctional queues.

Fix this by only configuring RSS with the number of active queues.

Signed-off-by: Mitch Williams &lt;mitch.a.williams@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i40evf: fix panic during MTU change</title>
<updated>2015-06-26T09:51:31+00:00</updated>
<author>
<name>Mitch Williams</name>
<email>mitch.a.williams@intel.com</email>
</author>
<published>2015-06-19T15:56:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=67c818a1d58c7897b8a6f531684516f9c236fe1b'/>
<id>67c818a1d58c7897b8a6f531684516f9c236fe1b</id>
<content type='text'>
Down was requesting queue disables, but then exited immediately
without waiting for the queues to actually disable.  This could
allow any function called after i40evf_down to run immediately,
including i40evf_up, and causes a memory leak.

Removing the whole reinit_locked function is the best way
to go about this, and allows for the driver to handle the
state changes by requesting reset from the periodic timer.

Also, add a couple WARN_ONs in slow path to help us recognize
if we re-introduce this issue or missed any cases.

Signed-off-by: Mitch Williams &lt;mitch.a.williams@intel.com&gt;
Signed-off-by: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Down was requesting queue disables, but then exited immediately
without waiting for the queues to actually disable.  This could
allow any function called after i40evf_down to run immediately,
including i40evf_up, and causes a memory leak.

Removing the whole reinit_locked function is the best way
to go about this, and allows for the driver to handle the
state changes by requesting reset from the periodic timer.

Also, add a couple WARN_ONs in slow path to help us recognize
if we re-introduce this issue or missed any cases.

Signed-off-by: Mitch Williams &lt;mitch.a.williams@intel.com&gt;
Signed-off-by: Jesse Brandeburg &lt;jesse.brandeburg@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>e1000e: i219 - k1 workaround for LPT is not required for SPT</title>
<updated>2015-06-26T09:47:37+00:00</updated>
<author>
<name>Yanir Lubetkin</name>
<email>yanirx.lubetkin@intel.com</email>
</author>
<published>2015-06-09T22:16:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=352f8ead753402d6c0496cb83b902128925459eb'/>
<id>352f8ead753402d6c0496cb83b902128925459eb</id>
<content type='text'>
In SPT hardware does not require this driver workaround.
Removed the conditional that caused K1 workaround execution on SPT.

Signed-off-by: Yanir Lubetkin &lt;yanirx.lubetkin@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;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In SPT hardware does not require this driver workaround.
Removed the conditional that caused K1 workaround execution on SPT.

Signed-off-by: Yanir Lubetkin &lt;yanirx.lubetkin@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;
</pre>
</div>
</content>
</entry>
<entry>
<title>e1000e: i219 - Increase minimum FIFO read/write min gap</title>
<updated>2015-06-26T09:45:50+00:00</updated>
<author>
<name>Yanir Lubetkin</name>
<email>yanirx.lubetkin@intel.com</email>
</author>
<published>2015-06-09T22:16:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=93cbfc709047a5bc3f8d86e0b55079b5077c8e00'/>
<id>93cbfc709047a5bc3f8d86e0b55079b5077c8e00</id>
<content type='text'>
Due to clocking changes in the Skylake platform, there was i219
data corruption. To work around this, HW team reported the need
to increase the minimum gap between the PHY FIFO read and write pointers.

Signed-off-by: Yanir Lubetkin &lt;yanirx.lubetkin@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;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Due to clocking changes in the Skylake platform, there was i219
data corruption. To work around this, HW team reported the need
to increase the minimum gap between the PHY FIFO read and write pointers.

Signed-off-by: Yanir Lubetkin &lt;yanirx.lubetkin@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;
</pre>
</div>
</content>
</entry>
<entry>
<title>e1000e: i219 - increase IPG for speed 10/100 full duplex</title>
<updated>2015-06-26T09:43:44+00:00</updated>
<author>
<name>Yanir Lubetkin</name>
<email>yanirx.lubetkin@intel.com</email>
</author>
<published>2015-06-09T22:15:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=69cfbc95bdbfa2bd9a82f27dc131b08c48542f19'/>
<id>69cfbc95bdbfa2bd9a82f27dc131b08c48542f19</id>
<content type='text'>
In SPT/i219, there were CRC errors in speed 10/100 full duplex.
The solution given by the HW team is to increase the IPG from 8 to 0xC

Signed-off-by: Yanir Lubetkin &lt;yanirx.lubetkin@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;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In SPT/i219, there were CRC errors in speed 10/100 full duplex.
The solution given by the HW team is to increase the IPG from 8 to 0xC

Signed-off-by: Yanir Lubetkin &lt;yanirx.lubetkin@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;
</pre>
</div>
</content>
</entry>
<entry>
<title>e1000e: i219 - fix to enable both ULP and EEE in Sx state</title>
<updated>2015-06-26T09:42:24+00:00</updated>
<author>
<name>Yanir Lubetkin</name>
<email>yanirx.lubetkin@intel.com</email>
</author>
<published>2015-06-09T22:15:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6607c99e7034e7565a1559a24dd35083d6719788'/>
<id>6607c99e7034e7565a1559a24dd35083d6719788</id>
<content type='text'>
In i219, there is a hardware bug that prevented ULP entry.
A side effect of the original software fix for this was that EEE in
Sx couldn't be enabled.
This patch implements a modified flow that allows both ULP and EEE in Sx.

Signed-off-by: Yanir Lubetkin &lt;yanirx.lubetkin@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;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In i219, there is a hardware bug that prevented ULP entry.
A side effect of the original software fix for this was that EEE in
Sx couldn't be enabled.
This patch implements a modified flow that allows both ULP and EEE in Sx.

Signed-off-by: Yanir Lubetkin &lt;yanirx.lubetkin@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;
</pre>
</div>
</content>
</entry>
<entry>
<title>e1000e: synchronization of MAC-PHY interface only on non- ME systems</title>
<updated>2015-06-26T09:39:39+00:00</updated>
<author>
<name>Yanir Lubetkin</name>
<email>yanirx.lubetkin@intel.com</email>
</author>
<published>2015-06-09T22:15:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=beee8072c39cee74d4ff6e3b4ca8942f9966ed2e'/>
<id>beee8072c39cee74d4ff6e3b4ca8942f9966ed2e</id>
<content type='text'>
On power up, the MAC - PHY interface needs to be set to PCIe, even if
cable is disconnected.  In ME systems, the ME handles this on exit from
Sx state. In non-ME, the driver handles it. Added a check for non-ME
system to the driver code that handles that.

Signed-off-by: Yanir Lubetkin &lt;yanirx.lubetkin@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;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On power up, the MAC - PHY interface needs to be set to PCIe, even if
cable is disconnected.  In ME systems, the ME handles this on exit from
Sx state. In non-ME, the driver handles it. Added a check for non-ME
system to the driver code that handles that.

Signed-off-by: Yanir Lubetkin &lt;yanirx.lubetkin@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;
</pre>
</div>
</content>
</entry>
<entry>
<title>e1000e: fix locking issue with e1000e_disable_aspm</title>
<updated>2015-06-26T09:38:28+00:00</updated>
<author>
<name>Yanir Lubetkin</name>
<email>yanirx.lubetkin@intel.com</email>
</author>
<published>2015-06-09T22:15:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=beb0a1520bec17cfaf0c3c77bbdd56cbf942883a'/>
<id>beb0a1520bec17cfaf0c3c77bbdd56cbf942883a</id>
<content type='text'>
e1000e_disable_aspm called pci_disable_link_state_locked which requires
pci_bus_sem to be held, but is also called from places where this semaphore
was not previously acquired. This patch implements two flavors of
disable_aspm, one that acquires the lock, and the other (_locked) which
should be called when the semaphore is already acquired.

Signed-off-by: Yanir Lubetkin &lt;yanirx.lubetkin@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;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
e1000e_disable_aspm called pci_disable_link_state_locked which requires
pci_bus_sem to be held, but is also called from places where this semaphore
was not previously acquired. This patch implements two flavors of
disable_aspm, one that acquires the lock, and the other (_locked) which
should be called when the semaphore is already acquired.

Signed-off-by: Yanir Lubetkin &lt;yanirx.lubetkin@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;
</pre>
</div>
</content>
</entry>
</feed>
