<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net/ethernet/intel, branch v3.18.62</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.18.62</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.18.62'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2017-05-08T05:44:12+00:00</updated>
<entry>
<title>e1000e: fix call to do_div() to use u64 arg</title>
<updated>2017-05-08T05:44:12+00:00</updated>
<author>
<name>Jeff Kirsher</name>
<email>jeffrey.t.kirsher@intel.com</email>
</author>
<published>2015-05-02T08:20:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8d86ef0c8958e5af95d3cef781bf3d44cbd21fef'/>
<id>urn:sha1:8d86ef0c8958e5af95d3cef781bf3d44cbd21fef</id>
<content type='text'>
commit 30544af5483755b11bb5924736e9e0b45ef0644a upstream.

We were using s64 for lat_ns (latency nano-second value) since in
our calculations a negative value could be a resultant.  For negative
values, we then assign lat_ns to be zero, so the value passed to
do_div() was never negative, but do_div() expects the argument type
to be u64, so do a cast to resolve a compile warning seen on
PowerPC.

CC: Yanjiang Jin &lt;yanjiang.jin@windriver.com&gt;
CC: Yanir Lubetkin &lt;yanirx.lubetkin@intel.com&gt;
Reported-by: Yanjiang Jin &lt;yanjiang.jin@windriver.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>igb: add i211 to i210 PHY workaround</title>
<updated>2017-04-22T05:15:05+00:00</updated>
<author>
<name>Todd Fujinaka</name>
<email>todd.fujinaka@intel.com</email>
</author>
<published>2016-11-28T17:09:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=230a372ff7316c9a22619257c1ad8974cb96daa5'/>
<id>urn:sha1:230a372ff7316c9a22619257c1ad8974cb96daa5</id>
<content type='text'>
commit 5bc8c230e2a993b49244f9457499f17283da9ec7 upstream.

i210 and i211 share the same PHY but have different PCI IDs. Don't
forget i211 for any i210 workarounds.

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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>igb: Workaround for igb i210 firmware issue</title>
<updated>2017-04-22T05:15:05+00:00</updated>
<author>
<name>Chris J Arges</name>
<email>christopherarges@gmail.com</email>
</author>
<published>2016-11-02T14:13:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6446e0ba431baccb80f844de751121344e8fb934'/>
<id>urn:sha1:6446e0ba431baccb80f844de751121344e8fb934</id>
<content type='text'>
commit 4e684f59d760a2c7c716bb60190783546e2d08a1 upstream.

Sometimes firmware may not properly initialize I347AT4_PAGE_SELECT causing
the probe of an igb i210 NIC to fail. This patch adds an addition zeroing
of this register during igb_get_phy_id to workaround this issue.

Thanks for Jochen Henneberg for the idea and original patch.

Signed-off-by: Chris J Arges &lt;christopherarges@gmail.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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>i40e: Reduce stack in i40e_dbg_dump_desc</title>
<updated>2017-02-08T08:43:04+00:00</updated>
<author>
<name>Joe Perches</name>
<email>joe@perches.com</email>
</author>
<published>2014-11-18T05:53:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=696e37395a2a4b72e48a995f3a45312d34326c11'/>
<id>urn:sha1:696e37395a2a4b72e48a995f3a45312d34326c11</id>
<content type='text'>
commit e6c97234d1b18d4751671df15d52e29daa8a7ba8 upstream.

Reduce stack use by using kmemdup and not using a very
large struct on stack.

In function ‘i40e_dbg_dump_desc’:
warning: the frame size of 8192 bytes is larger than 2048 bytes [-Wframe-larger-than=]

Signed-off-by: Joe Perches &lt;joe@perches.com&gt;
Tested-by: Jim Young &lt;jamesx.m.young@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>
</entry>
<entry>
<title>igb: do not re-init SR-IOV during probe</title>
<updated>2015-10-28T02:14:21+00:00</updated>
<author>
<name>Stefan Assmann</name>
<email>sassmann@kpanic.de</email>
</author>
<published>2015-07-10T13:01:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=730e73dd7df6f51eaa1ee8a14bc57c21b55b6642'/>
<id>urn:sha1:730e73dd7df6f51eaa1ee8a14bc57c21b55b6642</id>
<content type='text'>
[ Upstream commit 6423fc34160939142d72ffeaa2db6408317f54df ]

During driver probing the following code path is triggered.
igb_probe
-&gt;igb_sw_init
  -&gt;igb_probe_vfs
    -&gt;igb_pci_enable_sriov
      -&gt;igb_sriov_reinit

Doing the SR-IOV re-init is not necessary during probing since we're
starting from scratch. Here we can call igb_enable_sriov() right away.

Running igb_sriov_reinit() during igb_probe() also seems to cause
occasional packet loss on some onboard 82576 NICs. Reproduced on
Dell and HP servers with onboard 82576 NICs.
Example:
Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01)
Subsystem: Dell Device [1028:0481]

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: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>igb: Fix oops caused by missing queue pairing</title>
<updated>2015-10-27T13:33:08+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.radix-linux.su/kernel/linux.git/commit/?id=5be042b1917ddf444c20f4e12856535307b37c01'/>
<id>urn:sha1:5be042b1917ddf444c20f4e12856535307b37c01</id>
<content type='text'>
[ Upstream commit 72ddef0506da852dc82f078f37ced8ef4d74a2bf ]

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")
CC: stable &lt;stable@vger.kernel.org&gt;
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: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>e1000: add dummy allocator to fix race condition between mtu change and netpoll</title>
<updated>2015-05-17T23:12:27+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.radix-linux.su/kernel/linux.git/commit/?id=fcea4d66b0d0660439f6a2eb5b3894d7ee5fd136'/>
<id>urn:sha1:fcea4d66b0d0660439f6a2eb5b3894d7ee5fd136</id>
<content type='text'>
[ Upstream commit 08e8331654d1d7b2c58045e549005bc356aa7810 ]

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: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>i40e: adds FCoE configure option</title>
<updated>2015-01-27T16:29:40+00:00</updated>
<author>
<name>Vasu Dev</name>
<email>vasu.dev@intel.com</email>
</author>
<published>2015-01-14T13:14:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d8682e1d2663f516d0da60ecdcbbcc77c78af8b3'/>
<id>urn:sha1:d8682e1d2663f516d0da60ecdcbbcc77c78af8b3</id>
<content type='text'>
commit 776d4e9f5c0229037707f692b386b1f2a5bac054 upstream.

Adds FCoE config option I40E_FCOE, so that FCoE can be enabled
as needed but otherwise have it disabled by default.

This also eliminate multiple FCoE config checks, instead now just
one config check for CONFIG_I40E_FCOE.

The I40E FCoE was added with 3.17 kernel and therefore this patch
shall be applied to stable 3.17 kernel also.

Signed-off-by: Vasu Dev &lt;vasu.dev@intel.com&gt;
Tested-by: Jim Young &lt;jamesx.m.young@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>
</entry>
<entry>
<title>net: Check for presence of IFLA_AF_SPEC</title>
<updated>2014-11-26T20:29:01+00:00</updated>
<author>
<name>Thomas Graf</name>
<email>tgraf@suug.ch</email>
</author>
<published>2014-11-26T12:42:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4ea85e831e290cd967d161c66d0a3cf8be39f1f6'/>
<id>urn:sha1:4ea85e831e290cd967d161c66d0a3cf8be39f1f6</id>
<content type='text'>
ndo_bridge_setlink() is currently only called on the slave if
IFLA_AF_SPEC is set but this is a very fragile assumption and may
change in the future.

Cc: Ajit Khaparde &lt;ajit.khaparde@emulex.com&gt;
Cc: John Fastabend &lt;john.r.fastabend@intel.com&gt;
Signed-off-by: Thomas Graf &lt;tgraf@suug.ch&gt;
Acked-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: Validate IFLA_BRIDGE_MODE attribute length</title>
<updated>2014-11-26T20:29:00+00:00</updated>
<author>
<name>Thomas Graf</name>
<email>tgraf@suug.ch</email>
</author>
<published>2014-11-26T12:42:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b7c1a314112785c319b2ba2dc8e73497714e42a1'/>
<id>urn:sha1:b7c1a314112785c319b2ba2dc8e73497714e42a1</id>
<content type='text'>
Payload is currently accessed blindly and may exceed valid message
boundaries.

Fixes: a77dcb8c8 ("be2net: set and query VEB/VEPA mode of the PF interface")
Fixes: 815cccbf1 ("ixgbe: add setlink, getlink support to ixgbe and ixgbevf")
Cc: Ajit Khaparde &lt;ajit.khaparde@emulex.com&gt;
Cc: John Fastabend &lt;john.r.fastabend@intel.com&gt;
Signed-off-by: Thomas Graf &lt;tgraf@suug.ch&gt;
Acked-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Acked-by: John Fastabend &lt;john.r.fastabend@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
