linux-toradex.git/drivers/net/ethernet, branch v3.18.18

bnx2x: fix lockdep splat

2015-07-05T14:13:00+00:00

[ Upstream commit d53c66a5b80698620f7c9ba2372fff4017e987b8 ]

Michel reported following lockdep splat

[   44.718117] INFO: trying to register non-static key.
[   44.723081] the code is fine but needs lockdep annotation.
[   44.728559] turning off the locking correctness validator.
[   44.734036] CPU: 8 PID: 5483 Comm: ethtool Not tainted 4.1.0
[   44.770289] Call Trace:
[   44.772741]  [] dump_stack+0x4c/0x65
[   44.777879]  [] ? console_unlock+0x1f1/0x510
[   44.783708]  [] __lock_acquire+0x1d05/0x1f10
[   44.789538]  [] ? mark_held_locks+0x6a/0x90
[   44.795276]  [] ? trace_hardirqs_on_caller+0x105/0x1d0
[   44.801967]  [] ? trace_hardirqs_on+0xd/0x10
[   44.807793]  [] ? hrtimer_try_to_cancel+0x4a/0x250
[   44.814142]  [] lock_acquire+0xb6/0x290
[   44.819537]  [] ? flush_work+0x5/0x280
[   44.824844]  [] flush_work+0x3d/0x280
[   44.830061]  [] ? flush_work+0x5/0x280
[   44.835366]  [] ? schedule_hrtimeout_range+0x13/0x20
[   44.841889]  [] ? usleep_range+0x4b/0x50
[   44.847365]  [] ? mark_held_locks+0x6a/0x90
[   44.853102]  [] ? __cancel_work_timer+0x105/0x1c0
[   44.859359]  [] ? trace_hardirqs_on_caller+0x105/0x1d0
[   44.866045]  [] __cancel_work_timer+0x9f/0x1c0
[   44.872048]  [] ? bnx2x_func_stop+0x42/0x90 [bnx2x]
[   44.878481]  [] cancel_work_sync+0x10/0x20
[   44.884134]  [] bnx2x_chip_cleanup+0x245/0x730 [bnx2x]
[   44.890829]  [] ? up+0x32/0x50
[   44.895439]  [] ? del_timer_sync+0x5/0xd0
[   44.901005]  [] bnx2x_nic_unload+0x20d/0x8e0 [bnx2x]
[   44.907527]  [] ? might_fault+0x5f/0xb0
[   44.912921]  [] bnx2x_reload_if_running+0x2c/0x50 [bnx2x]
[   44.919879]  [] bnx2x_set_ringparam+0x2b5/0x460 [bnx2x]
[   44.926664]  [] dev_ethtool+0x55b/0x1c40
[   44.932148]  [] ? rtnl_lock+0x17/0x20
[   44.937364]  [] dev_ioctl+0x17b/0x630
[   44.942582]  [] sock_do_ioctl+0x5d/0x70
[   44.947972]  [] sock_ioctl+0x73/0x280
[   44.953192]  [] do_vfs_ioctl+0x88/0x5b0
[   44.958587]  [] ? up_read+0x23/0x40
[   44.963631]  [] ? __fget_light+0x6c/0xa0
[   44.969105]  [] SyS_ioctl+0x91/0xb0
[   44.974149]  [] system_call_fastpath+0x12/0x6f

As bnx2x_init_ptp() is only called if bp->flags contains PTP_SUPPORTED,
we also need to guard bnx2x_stop_ptp() with same condition, otherwise
ptp_task workqueue is not initialized and kernel barfs on
cancel_work_sync()

Fixes: eeed018cbfa30 ("bnx2x: Add timestamping and PTP hardware clock support")
Reported-by: Michel Lespinasse 
Signed-off-by: Eric Dumazet 
Cc: Michal Kalderon 
Cc: Ariel Elior 
Cc: Yuval Mintz 
Cc: David Decotigny 
Acked-by: Sony Chacko 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net/mlx4_en: Wake TX queues only when there's enough room

2015-07-05T14:12:59+00:00

[ Upstream commit 488a9b48e398b157703766e2cd91ea45ac6997c5 ]

Indication of a single completed packet, marked by txbbs_skipped
being bigger then zero, in not enough in order to wake up a
stopped TX queue. The completed packet may contain a single TXBB,
while next packet to be sent (after the wake up) may have multiple
TXBBs (LSO/TSO packets for example), causing overflow in queue followed
by WQE corruption and TX queue timeout.
Instead, wake the stopped queue only when there's enough room for the
worst case (maximum sized WQE) packet that we should need to handle after
the queue is opened again.

Also created an helper routine - mlx4_en_is_tx_ring_full, which checks
if the current TX ring is full or not. It provides better code readability
and removes code duplication.

Signed-off-by: Ido Shamay 
Signed-off-by: Or Gerlitz 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: mvneta: disable IP checksum with jumbo frames for Armada 370

2015-07-05T14:12:55+00:00

[ Upstream commit b65657fc240ae6c1d2a1e62db9a0e61ac9631d7a ]

The Ethernet controller found in the Armada 370, 380 and 385 SoCs don't
support TCP/IP checksumming with frame sizes larger than 1600 bytes.

This patch fixes the issue by disabling the features NETIF_F_IP_CSUM and
NETIF_F_TSO for the Armada 370 and compatibles SoCs when the MTU is set
to a value greater than 1600 bytes.

Signed-off-by: Simon Guinot 
Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
Cc:  # v3.8+
Acked-by: Thomas Petazzoni 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

net: mvneta: introduce compatible string "marvell, armada-xp-neta"

2015-07-05T14:12:54+00:00

[ Upstream commit f522a975a8101895a85354b9c143f41b8248e71a ]

The mvneta driver supports the Ethernet IP found in the Armada 370, XP,
380 and 385 SoCs. Since at least one more hardware feature is available
for the Armada XP SoCs then a way to identify them is needed.

This patch introduces a new compatible string "marvell,armada-xp-neta".

Signed-off-by: Simon Guinot 
Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
Cc:  # v3.8+
Acked-by: Gregory CLEMENT 
Acked-by: Thomas Petazzoni 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

stmmac: troubleshoot unexpected bits in des0 & des1

2015-07-05T14:12:49+00:00

[ Upstream commit f1590670ce069eefeb93916391a67643e6ad1630 ]

Current implementation of descriptor init procedure only takes
care about setting/clearing ownership flag in "des0"/"des1"
fields while it is perfectly possible to get unexpected bits
set because of the following factors:

 [1] On driver probe underlying memory allocated with
     dma_alloc_coherent() might not be zeroed and so
     it will be filled with garbage.

 [2] During driver operation some bits could be set by SD/MMC
     controller (for example error flags etc).

And unexpected and/or randomly set flags in "des0"/"des1"
fields may lead to unpredictable behavior of GMAC DMA block.

This change addresses both items above with:

 [1] Use of dma_zalloc_coherent() instead of simple
     dma_alloc_coherent() to make sure allocated memory is
     zeroed. That shouldn't affect performance because
     this allocation only happens once on driver probe.

 [2] Do explicit zeroing of both "des0" and "des1" fields
     of all buffer descriptors during initialization of
     DMA transfer.

And while at it fixed identation of dma_free_coherent()
counterpart as well.

Signed-off-by: Alexey Brodkin 
Cc: Giuseppe Cavallaro 
Cc: arc-linux-dev@synopsys.com
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Cc: David Miller 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

mlx5: wrong page mask if CONFIG_ARCH_DMA_ADDR_T_64BIT enabled for 32Bit architectures

2015-06-28T17:39:25+00:00

[ Upstream commit 59d2d18cc4e9ba30b370db18d0e02d792699da96 ]

If CONFIG_ARCH_DMA_ADDR_T_64BIT enabled for x86 systems and physical
memory is more than 4GB, dma_map_page may return a valid memory
address which greater than 0xffffffff. As a result, the mlx5 device page
allocator RB tree will be initialized with valid addresses greater than
0xfffffff.

However, (addr & PAGE_MASK) set the high four bytes to zeros. So, it's
impossible for the function, free_4k, to release the pages whose
addresses greater than 4GB. Memory leaks. And mlx5_ib module can't
release the pages when user try to remove the module, as a result,
system hang.

[root@rdma05 root]# dmesg  | grep addr | head
addr             = 3fe384000
addr & PAGE_MASK =  fe384000
[root@rdma05 root]# rmmod mlx5_ib   <---- hang on

---------------------- cosnole log -----------------
mlx5_ib 0000:04:00.0: irq 138 for MSI/MSI-X
  alloc irq_desc for 139 on node -1
  alloc kstat_irqs on node -1
mlx5_ib 0000:04:00.0: irq 139 for MSI/MSI-X
0000:04:00.0:free_4k:221:(pid 1519): page not found
0000:04:00.0:free_4k:221:(pid 1519): page not found
0000:04:00.0:free_4k:221:(pid 1519): page not found
0000:04:00.0:free_4k:221:(pid 1519): page not found
---------------------- cosnole log -----------------

Fixes: bf0bf77f6519 ('mlx5: Support communicating arbitrary host page size to firmware')
Signed-off-by: Honggang Li 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin

be2net: Replace dma/pci_alloc_coherent() calls with dma_zalloc_coherent()

2015-06-15T18:26:54+00:00

[ Upstream commit e51000db4c880165eab06ec0990605f24e75203f ]

There are several places in the driver (all in control paths) where
coherent dma memory is being allocated using either dma_alloc_coherent()
or the deprecated pci_alloc_consistent(). All these calls should be
changed to use dma_zalloc_coherent() to avoid uninitialized fields in
data structures backed by this memory.

Reported-by: Joerg Roedel 
Tested-by: Joerg Roedel 
Signed-off-by: Sriharsha Basavapatna 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

e1000: add dummy allocator to fix race condition between mtu change and netpoll

2015-05-17T23:12:27+00:00

[ 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 -> e1000_down -> e1000_clean_all_rx_rings ->
        e1000_clean_rx_ring

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

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

alloc_jumbo finds the buffers already != NULL, since data (shared with
page in e1000_rx_buffer->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: [] put_compound_page+0x7e/0x330

    [...]

Call Trace:
 [] put_page+0x55/0x60
 [] e1000_clean_rx_ring+0x134/0x200
 [] e1000_clean_all_rx_rings+0x45/0x60
 [] e1000_down+0x1c0/0x1d0
 [] ? deactivate_slab+0x7f0/0x840
 [] e1000_change_mtu+0xdc/0x170
 [] dev_set_mtu+0xa0/0x140
 [] do_setlink+0x218/0xac0
 [] ? nla_parse+0xb9/0x120
 [] rtnl_newlink+0x6d0/0x890
 [] ? kvm_clock_read+0x20/0x40
 [] ? sched_clock_cpu+0xa8/0x100
 [] 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 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Sasha Levin

net/mlx4_en: Schedule napi when RX buffers allocation fails

2015-05-11T11:07:53+00:00

[ Upstream commit 07841f9d94c11afe00c0498cf242edf4075729f4 ]

When system is out of memory, refilling of RX buffers fails while
the driver continue to pass the received packets to the kernel stack.
At some point, when all RX buffers deplete, driver may fall into a
sleep, and not recover when memory for new RX buffers is once again
availible. This is because hardware does not have valid descriptors,
so no interrupt will be generated for the driver to return to work
in napi context. Fix it by schedule the napi poll function from
stats_task delayed workqueue, as long as the allocations fail.

Signed-off-by: Ido Shamay 
Signed-off-by: Amir Vadai 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

mlx4: Fix tx ring affinity_mask creation

2015-05-11T11:07:53+00:00

[ Upstream commit 42eab005a5dd5d7ea2b0328aecc4d6cc0c23c9c2 ]

By default, the number of tx queues is limited by the number of online cpus
in mlx4_en_get_profile(). However, this limit no longer holds after the
ethtool .set_channels method has been called. In that situation, the driver
may access invalid bits of certain cpumask variables when queue_index >=
nr_cpu_ids.

Signed-off-by: Benjamin Poirier 
Acked-by: Ido Shamay 
Fixes: d03a68f ("net/mlx4_en: Configure the XPS queue mapping on driver load")
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin