linux-stable.git/drivers/net, branch v3.13.6

can: kvaser_usb: check number of channels returned by HW

2014-03-07T06:06:23+00:00

commit 862474f8b46f6c1e600d4934e40ba40646c696ec upstream.

It is needed to check the number of channels returned by the HW because it
cannot be greater than MAX_NET_DEVICES otherwise it will crash.

Signed-off-by: Olivier Sobrie 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

net: mvneta: replace Tx timer with a real interrupt

2014-03-07T06:06:15+00:00

[ Upstream commit 71f6d1b31fb1f278a345a30a2180515adc7d80ae ]

Right now the mvneta driver doesn't handle Tx IRQ, and relies on two
mechanisms to flush Tx descriptors : a flush at the end of mvneta_tx()
and a timer. If a burst of packets is emitted faster than the device
can send them, then the queue is stopped until next wake-up of the
timer 10ms later. This causes jerky output traffic with bursts and
pauses, making it difficult to reach line rate with very few streams.

A test on UDP traffic shows that it's not possible to go beyond 134
Mbps / 12 kpps of outgoing traffic with 1500-bytes IP packets. Routed
traffic tends to observe pauses as well if the traffic is bursty,
making it even burstier after the wake-up.

It seems that this feature was inherited from the original driver but
nothing there mentions any reason for not using the interrupt instead,
which the chip supports.

Thus, this patch enables Tx interrupts and removes the timer. It does
the two at once because it's not really possible to make the two
mechanisms coexist, so a split patch doesn't make sense.

First tests performed on a Mirabox (Armada 370) show that less CPU
seems to be used when sending traffic. One reason might be that we now
call the mvneta_tx_done_gbe() with a mask indicating which queues have
been done instead of looping over all of them.

The same UDP test above now happily reaches 987 Mbps / 87.7 kpps.
Single-stream TCP traffic can now more easily reach line rate. HTTP
transfers of 1 MB objects over a single connection went from 730 to
840 Mbps. It is even possible to go significantly higher (>900 Mbps)
by tweaking tcp_tso_win_divisor.

Cc: Thomas Petazzoni 
Cc: Gregory CLEMENT 
Cc: Arnaud Ebalard 
Cc: Eric Dumazet 
Tested-by: Arnaud Ebalard 
Signed-off-by: Willy Tarreau 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: mvneta: add missing bit descriptions for interrupt masks and causes

2014-03-07T06:06:15+00:00

[ Upstream commit 40ba35e74fa56866918d2f3bc0528b5b92725d5e ]

Marvell has not published the chip's datasheet yet, so it's very hard
to find the relevant bits to manipulate to change the IRQ behaviour.
Fortunately, these bits are described in the proprietary LSP patch set
which is publicly available here :

    http://www.plugcomputer.org/downloads/mirabox/

So let's put them back in the driver in order to reduce the burden of
current and future maintenance.

Cc: Thomas Petazzoni 
Cc: Gregory CLEMENT 
Tested-by: Arnaud Ebalard 
Signed-off-by: Willy Tarreau 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: mvneta: do not schedule in mvneta_tx_timeout

2014-03-07T06:06:14+00:00

[ Upstream commit 290213667ab53a95456397763205e4b1e30f46b5 ]

If a queue timeout is reported, we can oops because of some
schedules while the caller is atomic, as shown below :

  mvneta d0070000.ethernet eth0: tx timeout
  BUG: scheduling while atomic: bash/1528/0x00000100
  Modules linked in: slhttp_ethdiv(C) [last unloaded: slhttp_ethdiv]
  CPU: 2 PID: 1528 Comm: bash Tainted: G        WC   3.13.0-rc4-mvebu-nf #180
  [] (unwind_backtrace+0x1/0x98) from [] (show_stack+0xb/0xc)
  [] (show_stack+0xb/0xc) from [] (dump_stack+0x4f/0x64)
  [] (dump_stack+0x4f/0x64) from [] (__schedule_bug+0x37/0x4c)
  [] (__schedule_bug+0x37/0x4c) from [] (__schedule+0x325/0x3ec)
  [] (__schedule+0x325/0x3ec) from [] (schedule_timeout+0xb7/0x118)
  [] (schedule_timeout+0xb7/0x118) from [] (msleep+0xf/0x14)
  [] (msleep+0xf/0x14) from [] (mvneta_stop_dev+0x21/0x194)
  [] (mvneta_stop_dev+0x21/0x194) from [] (mvneta_tx_timeout+0x19/0x24)
  [] (mvneta_tx_timeout+0x19/0x24) from [] (dev_watchdog+0x18b/0x1c4)
  [] (dev_watchdog+0x18b/0x1c4) from [] (call_timer_fn.isra.27+0x17/0x5c)
  [] (call_timer_fn.isra.27+0x17/0x5c) from [] (run_timer_softirq+0x115/0x170)
  [] (run_timer_softirq+0x115/0x170) from [] (__do_softirq+0xbd/0x1a8)
  [] (__do_softirq+0xbd/0x1a8) from [] (irq_exit+0x61/0x98)
  [] (irq_exit+0x61/0x98) from [] (handle_IRQ+0x27/0x60)
  [] (handle_IRQ+0x27/0x60) from [] (armada_370_xp_handle_irq+0x33/0xc8)
  [] (armada_370_xp_handle_irq+0x33/0xc8) from [] (__irq_usr+0x49/0x60)

Ben Hutchings attempted to propose a better fix consisting in using a
scheduled work for this, but while it fixed this panic, it caused other
random freezes and panics proving that the reset sequence in the driver
is unreliable and that additional fixes should be investigated.

When sending multiple streams over a link limited to 100 Mbps, Tx timeouts
happen from time to time, and the driver correctly recovers only when the
function is disabled.

Cc: Thomas Petazzoni 
Cc: Gregory CLEMENT 
Cc: Ben Hutchings 
Tested-by: Arnaud Ebalard 
Signed-off-by: Willy Tarreau 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: mvneta: use per_cpu stats to fix an SMP lock up

2014-03-07T06:06:14+00:00

[ Upstream commit 74c41b048db1073a04827d7f39e95ac1935524cc ]

Stats writers are mvneta_rx() and mvneta_tx(). They don't lock anything
when they update the stats, and as a result, it randomly happens that
the stats freeze on SMP if two updates happen during stats retrieval.
This is very easily reproducible by starting two HTTP servers and binding
each of them to a different CPU, then consulting /proc/net/dev in loops
during transfers, the interface should immediately lock up. This issue
also randomly happens upon link state changes during transfers, because
the stats are collected in this situation, but it takes more attempts to
reproduce it.

The comments in netdevice.h suggest using per_cpu stats instead to get
rid of this issue.

This patch implements this. It merges both rx_stats and tx_stats into
a single "stats" member with a single syncp. Both mvneta_rx() and
mvneta_rx() now only update the a single CPU's counters.

In turn, mvneta_get_stats64() does the summing by iterating over all CPUs
to get their respective stats.

With this change, stats are still correct and no more lockup is encountered.

Note that this bug was present since the first import of the mvneta
driver.  It might make sense to backport it to some stable trees. If
so, it depends on "d33dc73 net: mvneta: increase the 64-bit rx/tx stats
out of the hot path".

Cc: Thomas Petazzoni 
Cc: Gregory CLEMENT 
Reviewed-by: Eric Dumazet 
Tested-by: Arnaud Ebalard 
Signed-off-by: Willy Tarreau 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: mvneta: increase the 64-bit rx/tx stats out of the hot path

2014-03-07T06:06:14+00:00

[ Upstream commit dc4277dd41a80fd5f29a90412ea04bc3ba54fbf1 ]

Better count packets and bytes in the stack and on 32 bit then
accumulate them at the end for once. This saves two memory writes
and two memory barriers per packet. The incoming packet rate was
increased by 4.7% on the Openblocks AX3 thanks to this.

Cc: Thomas Petazzoni 
Cc: Gregory CLEMENT 
Reviewed-by: Eric Dumazet 
Tested-by: Arnaud Ebalard 
Signed-off-by: Willy Tarreau 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bonding: 802.3ad: make aggregator_identifier bond-private

2014-03-07T06:06:13+00:00

[ Upstream commit 163c8ff30dbe473abfbb24a7eac5536c87f3baa9 ]

aggregator_identifier is used to assign unique aggregator identifiers
to aggregators of a bond during device enslaving.

aggregator_identifier is currently a global variable that is zeroed in
bond_3ad_initialize().

This sequence will lead to duplicate aggregator identifiers for eth1 and eth3:

create bond0
change bond0 mode to 802.3ad
enslave eth0 to bond0 		//eth0 gets agg id 1
enslave eth1 to bond0 		//eth1 gets agg id 2
create bond1
change bond1 mode to 802.3ad
enslave eth2 to bond1		//aggregator_identifier is reset to 0
				//eth2 gets agg id 1
enslave eth3 to bond0 		//eth3 gets agg id 2

Fix this by making aggregator_identifier private to the bond.

Signed-off-by: Jiri Bohac 
Acked-by: Veaceslav Falico 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

usbnet: remove generic hard_header_len check

2014-03-07T06:06:13+00:00

[ Upstream commit eb85569fe2d06c2fbf4de7b66c263ca095b397aa ]

This patch removes a generic hard_header_len check from the usbnet
module that is causing dropped packages under certain circumstances
for devices that send rx packets that cross urb boundaries.

One example is the AX88772B which occasionally send rx packets that
cross urb boundaries where the remaining partial packet is sent with
no hardware header. When the buffer with a partial packet is of less
number of octets than the value of hard_header_len the buffer is
discarded by the usbnet module.

With AX88772B this can be reproduced by using ping with a packet
size between 1965-1976.

The bug has been reported here:

https://bugzilla.kernel.org/show_bug.cgi?id=29082

This patch introduces the following changes:
- Removes the generic hard_header_len check in the rx_complete
  function in the usbnet module.
- Introduces a ETH_HLEN check for skbs that are not cloned from
  within a rx_fixup callback.
- For safety a hard_header_len check is added to each rx_fixup
  callback function that could be affected by this change.
  These extra checks could possibly be removed by someone
  who has the hardware to test.
- Removes a call to dev_kfree_skb_any() and instead utilizes the
  dev->done list to queue skbs for cleanup.

The changes place full responsibility on the rx_fixup callback
functions that clone skbs to only pass valid skbs to the
usbnet_skb_return function.

Signed-off-by: Emil Goode 
Reported-by: Igor Gnatenko 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: asix: add missing flag to struct driver_info

2014-03-07T06:06:13+00:00

[ Upstream commit d43ff4cd798911736fb39025ec8004284b1b0bc2 ]

The struct driver_info ax88178_info is assigned the function
asix_rx_fixup_common as it's rx_fixup callback. This means that
FLAG_MULTI_PACKET must be set as this function is cloning the
data and calling usbnet_skb_return. Not setting this flag leads
to usbnet_skb_return beeing called a second time from within
the rx_process function in the usbnet module.

Signed-off-by: Emil Goode 
Reported-by: Bjørn Mork 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

hyperv: Fix the carrier status setting

2014-03-07T06:06:13+00:00

[ Upstream commit 891de74d693bb4fefe2efcc6432a4a9a9bee561e ]

Without this patch, the "cat /sys/class/net/ethN/operstate" shows
"unknown", and "ethtool ethN" shows "Link detected: yes", when VM
boots up with or without vNIC connected.

This patch fixed the problem.

Signed-off-by: Haiyang Zhang 
Reviewed-by: K. Y. Srinivasan 
Acked-by: Jason Wang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman