<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net, branch v3.10.55</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>macvlan: Initialize vlan_features to turn on offload support.</title>
<updated>2014-08-14T01:24:15+00:00</updated>
<author>
<name>Vlad Yasevich</name>
<email>vyasevic@redhat.com</email>
</author>
<published>2014-07-31T14:30:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d09fdc66ecb543136f9e3304c1b6071d3dae9792'/>
<id>d09fdc66ecb543136f9e3304c1b6071d3dae9792</id>
<content type='text'>
[ Upstream commit 081e83a78db9b0ae1f5eabc2dedecc865f509b98 ]

Macvlan devices do not initialize vlan_features.  As a result,
any vlan devices configured on top of macvlans perform very poorly.
Initialize vlan_features based on the vlan features of the lower-level
device.

Signed-off-by: Vlad Yasevich &lt;vyasevic@redhat.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>
[ Upstream commit 081e83a78db9b0ae1f5eabc2dedecc865f509b98 ]

Macvlan devices do not initialize vlan_features.  As a result,
any vlan devices configured on top of macvlans perform very poorly.
Initialize vlan_features based on the vlan features of the lower-level
device.

Signed-off-by: Vlad Yasevich &lt;vyasevic@redhat.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>inetpeer: get rid of ip_id_count</title>
<updated>2014-08-14T01:24:15+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2014-06-02T12:26:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ff1f69a89a613223c57c13190a6c9be928ac4b9d'/>
<id>ff1f69a89a613223c57c13190a6c9be928ac4b9d</id>
<content type='text'>
[ Upstream commit 73f156a6e8c1074ac6327e0abd1169e95eb66463 ]

Ideally, we would need to generate IP ID using a per destination IP
generator.

linux kernels used inet_peer cache for this purpose, but this had a huge
cost on servers disabling MTU discovery.

1) each inet_peer struct consumes 192 bytes

2) inetpeer cache uses a binary tree of inet_peer structs,
   with a nominal size of ~66000 elements under load.

3) lookups in this tree are hitting a lot of cache lines, as tree depth
   is about 20.

4) If server deals with many tcp flows, we have a high probability of
   not finding the inet_peer, allocating a fresh one, inserting it in
   the tree with same initial ip_id_count, (cf secure_ip_id())

5) We garbage collect inet_peer aggressively.

IP ID generation do not have to be 'perfect'

Goal is trying to avoid duplicates in a short period of time,
so that reassembly units have a chance to complete reassembly of
fragments belonging to one message before receiving other fragments
with a recycled ID.

We simply use an array of generators, and a Jenkin hash using the dst IP
as a key.

ipv6_select_ident() is put back into net/ipv6/ip6_output.c where it
belongs (it is only used from this file)

secure_ip_id() and secure_ipv6_id() no longer are needed.

Rename ip_select_ident_more() to ip_select_ident_segs() to avoid
unnecessary decrement/increment of the number of segments.

Signed-off-by: Eric Dumazet &lt;edumazet@google.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>
[ Upstream commit 73f156a6e8c1074ac6327e0abd1169e95eb66463 ]

Ideally, we would need to generate IP ID using a per destination IP
generator.

linux kernels used inet_peer cache for this purpose, but this had a huge
cost on servers disabling MTU discovery.

1) each inet_peer struct consumes 192 bytes

2) inetpeer cache uses a binary tree of inet_peer structs,
   with a nominal size of ~66000 elements under load.

3) lookups in this tree are hitting a lot of cache lines, as tree depth
   is about 20.

4) If server deals with many tcp flows, we have a high probability of
   not finding the inet_peer, allocating a fresh one, inserting it in
   the tree with same initial ip_id_count, (cf secure_ip_id())

5) We garbage collect inet_peer aggressively.

IP ID generation do not have to be 'perfect'

Goal is trying to avoid duplicates in a short period of time,
so that reassembly units have a chance to complete reassembly of
fragments belonging to one message before receiving other fragments
with a recycled ID.

We simply use an array of generators, and a Jenkin hash using the dst IP
as a key.

ipv6_select_ident() is put back into net/ipv6/ip6_output.c where it
belongs (it is only used from this file)

secure_ip_id() and secure_ipv6_id() no longer are needed.

Rename ip_select_ident_more() to ip_select_ident_segs() to avoid
unnecessary decrement/increment of the number of segments.

Signed-off-by: Eric Dumazet &lt;edumazet@google.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>bnx2x: fix crash during TSO tunneling</title>
<updated>2014-08-14T01:24:14+00:00</updated>
<author>
<name>Dmitry Kravkov</name>
<email>Dmitry.Kravkov@qlogic.com</email>
</author>
<published>2014-07-24T15:54:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f5980d099295d4113635ded88425834a38d17125'/>
<id>f5980d099295d4113635ded88425834a38d17125</id>
<content type='text'>
[ Upstream commit fe26566d8a05151ba1dce75081f6270f73ec4ae1 ]

When TSO packet is transmitted additional BD w/o mapping is used
to describe the packed. The BD needs special handling in tx
completion.

kernel: Call Trace:
kernel: &lt;IRQ&gt;  [&lt;ffffffff815e19ba&gt;] dump_stack+0x19/0x1b
kernel: [&lt;ffffffff8105dee1&gt;] warn_slowpath_common+0x61/0x80
kernel: [&lt;ffffffff8105df5c&gt;] warn_slowpath_fmt+0x5c/0x80
kernel: [&lt;ffffffff814a8c0d&gt;] ? find_iova+0x4d/0x90
kernel: [&lt;ffffffff814ab0e2&gt;] intel_unmap_page.part.36+0x142/0x160
kernel: [&lt;ffffffff814ad0e6&gt;] intel_unmap_page+0x26/0x30
kernel: [&lt;ffffffffa01f55d7&gt;] bnx2x_free_tx_pkt+0x157/0x2b0 [bnx2x]
kernel: [&lt;ffffffffa01f8dac&gt;] bnx2x_tx_int+0xac/0x220 [bnx2x]
kernel: [&lt;ffffffff8101a0d9&gt;] ? read_tsc+0x9/0x20
kernel: [&lt;ffffffffa01f8fdb&gt;] bnx2x_poll+0xbb/0x3c0 [bnx2x]
kernel: [&lt;ffffffff814d041a&gt;] net_rx_action+0x15a/0x250
kernel: [&lt;ffffffff81067047&gt;] __do_softirq+0xf7/0x290
kernel: [&lt;ffffffff815f3a5c&gt;] call_softirq+0x1c/0x30
kernel: [&lt;ffffffff81014d25&gt;] do_softirq+0x55/0x90
kernel: [&lt;ffffffff810673e5&gt;] irq_exit+0x115/0x120
kernel: [&lt;ffffffff815f4358&gt;] do_IRQ+0x58/0xf0
kernel: [&lt;ffffffff815e94ad&gt;] common_interrupt+0x6d/0x6d
kernel: &lt;EOI&gt;  [&lt;ffffffff810bbff7&gt;] ? clockevents_notify+0x127/0x140
kernel: [&lt;ffffffff814834df&gt;] ? cpuidle_enter_state+0x4f/0xc0
kernel: [&lt;ffffffff81483615&gt;] cpuidle_idle_call+0xc5/0x200
kernel: [&lt;ffffffff8101bc7e&gt;] arch_cpu_idle+0xe/0x30
kernel: [&lt;ffffffff810b4725&gt;] cpu_startup_entry+0xf5/0x290
kernel: [&lt;ffffffff815cfee1&gt;] start_secondary+0x265/0x27b
kernel: ---[ end trace 11aa7726f18d7e80 ]---

Fixes: a848ade408b ("bnx2x: add CSUM and TSO support for encapsulation protocols")
Reported-by: Yulong Pei &lt;ypei@redhat.com&gt;
Cc: Michal Schmidt &lt;mschmidt@redhat.com&gt;
Signed-off-by: Dmitry Kravkov &lt;Dmitry.Kravkov@qlogic.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>
[ Upstream commit fe26566d8a05151ba1dce75081f6270f73ec4ae1 ]

When TSO packet is transmitted additional BD w/o mapping is used
to describe the packed. The BD needs special handling in tx
completion.

kernel: Call Trace:
kernel: &lt;IRQ&gt;  [&lt;ffffffff815e19ba&gt;] dump_stack+0x19/0x1b
kernel: [&lt;ffffffff8105dee1&gt;] warn_slowpath_common+0x61/0x80
kernel: [&lt;ffffffff8105df5c&gt;] warn_slowpath_fmt+0x5c/0x80
kernel: [&lt;ffffffff814a8c0d&gt;] ? find_iova+0x4d/0x90
kernel: [&lt;ffffffff814ab0e2&gt;] intel_unmap_page.part.36+0x142/0x160
kernel: [&lt;ffffffff814ad0e6&gt;] intel_unmap_page+0x26/0x30
kernel: [&lt;ffffffffa01f55d7&gt;] bnx2x_free_tx_pkt+0x157/0x2b0 [bnx2x]
kernel: [&lt;ffffffffa01f8dac&gt;] bnx2x_tx_int+0xac/0x220 [bnx2x]
kernel: [&lt;ffffffff8101a0d9&gt;] ? read_tsc+0x9/0x20
kernel: [&lt;ffffffffa01f8fdb&gt;] bnx2x_poll+0xbb/0x3c0 [bnx2x]
kernel: [&lt;ffffffff814d041a&gt;] net_rx_action+0x15a/0x250
kernel: [&lt;ffffffff81067047&gt;] __do_softirq+0xf7/0x290
kernel: [&lt;ffffffff815f3a5c&gt;] call_softirq+0x1c/0x30
kernel: [&lt;ffffffff81014d25&gt;] do_softirq+0x55/0x90
kernel: [&lt;ffffffff810673e5&gt;] irq_exit+0x115/0x120
kernel: [&lt;ffffffff815f4358&gt;] do_IRQ+0x58/0xf0
kernel: [&lt;ffffffff815e94ad&gt;] common_interrupt+0x6d/0x6d
kernel: &lt;EOI&gt;  [&lt;ffffffff810bbff7&gt;] ? clockevents_notify+0x127/0x140
kernel: [&lt;ffffffff814834df&gt;] ? cpuidle_enter_state+0x4f/0xc0
kernel: [&lt;ffffffff81483615&gt;] cpuidle_idle_call+0xc5/0x200
kernel: [&lt;ffffffff8101bc7e&gt;] arch_cpu_idle+0xe/0x30
kernel: [&lt;ffffffff810b4725&gt;] cpu_startup_entry+0xf5/0x290
kernel: [&lt;ffffffff815cfee1&gt;] start_secondary+0x265/0x27b
kernel: ---[ end trace 11aa7726f18d7e80 ]---

Fixes: a848ade408b ("bnx2x: add CSUM and TSO support for encapsulation protocols")
Reported-by: Yulong Pei &lt;ypei@redhat.com&gt;
Cc: Michal Schmidt &lt;mschmidt@redhat.com&gt;
Signed-off-by: Dmitry Kravkov &lt;Dmitry.Kravkov@qlogic.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>net: mvneta: replace Tx timer with a real interrupt</title>
<updated>2014-08-07T21:30:27+00:00</updated>
<author>
<name>willy tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2014-01-16T07:20:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a733b535a48be3b3bbf04de22f048d850dd5b0c6'/>
<id>a733b535a48be3b3bbf04de22f048d850dd5b0c6</id>
<content type='text'>
commit 71f6d1b31fb1f278a345a30a2180515adc7d80ae upstream.

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 (&gt;900 Mbps)
by tweaking tcp_tso_win_divisor.

Cc: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Cc: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Cc: Arnaud Ebalard &lt;arno@natisbad.org&gt;
Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Tested-by: Arnaud Ebalard &lt;arno@natisbad.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&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 71f6d1b31fb1f278a345a30a2180515adc7d80ae upstream.

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 (&gt;900 Mbps)
by tweaking tcp_tso_win_divisor.

Cc: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Cc: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Cc: Arnaud Ebalard &lt;arno@natisbad.org&gt;
Cc: Eric Dumazet &lt;eric.dumazet@gmail.com&gt;
Tested-by: Arnaud Ebalard &lt;arno@natisbad.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&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>net: mvneta: add missing bit descriptions for interrupt masks and causes</title>
<updated>2014-08-07T21:30:27+00:00</updated>
<author>
<name>willy tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2014-01-16T07:20:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=15ca23fcd05bd77099da3ced60ea64a21d7e9252'/>
<id>15ca23fcd05bd77099da3ced60ea64a21d7e9252</id>
<content type='text'>
commit 40ba35e74fa56866918d2f3bc0528b5b92725d5e upstream.

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 &lt;thomas.petazzoni@free-electrons.com&gt;
Cc: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Tested-by: Arnaud Ebalard &lt;arno@natisbad.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&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 40ba35e74fa56866918d2f3bc0528b5b92725d5e upstream.

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 &lt;thomas.petazzoni@free-electrons.com&gt;
Cc: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Tested-by: Arnaud Ebalard &lt;arno@natisbad.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&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>net: mvneta: do not schedule in mvneta_tx_timeout</title>
<updated>2014-08-07T21:30:27+00:00</updated>
<author>
<name>willy tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2014-01-16T07:20:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=aaf7035af079d55b52179c6b5bd5f8d82fec696b'/>
<id>aaf7035af079d55b52179c6b5bd5f8d82fec696b</id>
<content type='text'>
commit 290213667ab53a95456397763205e4b1e30f46b5 upstream.

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
  [&lt;c0011bd9&gt;] (unwind_backtrace+0x1/0x98) from [&lt;c000f1ab&gt;] (show_stack+0xb/0xc)
  [&lt;c000f1ab&gt;] (show_stack+0xb/0xc) from [&lt;c02ad323&gt;] (dump_stack+0x4f/0x64)
  [&lt;c02ad323&gt;] (dump_stack+0x4f/0x64) from [&lt;c02abe67&gt;] (__schedule_bug+0x37/0x4c)
  [&lt;c02abe67&gt;] (__schedule_bug+0x37/0x4c) from [&lt;c02ae261&gt;] (__schedule+0x325/0x3ec)
  [&lt;c02ae261&gt;] (__schedule+0x325/0x3ec) from [&lt;c02adb97&gt;] (schedule_timeout+0xb7/0x118)
  [&lt;c02adb97&gt;] (schedule_timeout+0xb7/0x118) from [&lt;c0020a67&gt;] (msleep+0xf/0x14)
  [&lt;c0020a67&gt;] (msleep+0xf/0x14) from [&lt;c01dcbe5&gt;] (mvneta_stop_dev+0x21/0x194)
  [&lt;c01dcbe5&gt;] (mvneta_stop_dev+0x21/0x194) from [&lt;c01dcfe9&gt;] (mvneta_tx_timeout+0x19/0x24)
  [&lt;c01dcfe9&gt;] (mvneta_tx_timeout+0x19/0x24) from [&lt;c024afc7&gt;] (dev_watchdog+0x18b/0x1c4)
  [&lt;c024afc7&gt;] (dev_watchdog+0x18b/0x1c4) from [&lt;c0020b53&gt;] (call_timer_fn.isra.27+0x17/0x5c)
  [&lt;c0020b53&gt;] (call_timer_fn.isra.27+0x17/0x5c) from [&lt;c0020cad&gt;] (run_timer_softirq+0x115/0x170)
  [&lt;c0020cad&gt;] (run_timer_softirq+0x115/0x170) from [&lt;c001ccb9&gt;] (__do_softirq+0xbd/0x1a8)
  [&lt;c001ccb9&gt;] (__do_softirq+0xbd/0x1a8) from [&lt;c001cfad&gt;] (irq_exit+0x61/0x98)
  [&lt;c001cfad&gt;] (irq_exit+0x61/0x98) from [&lt;c000d4bf&gt;] (handle_IRQ+0x27/0x60)
  [&lt;c000d4bf&gt;] (handle_IRQ+0x27/0x60) from [&lt;c000843b&gt;] (armada_370_xp_handle_irq+0x33/0xc8)
  [&lt;c000843b&gt;] (armada_370_xp_handle_irq+0x33/0xc8) from [&lt;c000fba9&gt;] (__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 &lt;thomas.petazzoni@free-electrons.com&gt;
Cc: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Tested-by: Arnaud Ebalard &lt;arno@natisbad.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&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 290213667ab53a95456397763205e4b1e30f46b5 upstream.

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
  [&lt;c0011bd9&gt;] (unwind_backtrace+0x1/0x98) from [&lt;c000f1ab&gt;] (show_stack+0xb/0xc)
  [&lt;c000f1ab&gt;] (show_stack+0xb/0xc) from [&lt;c02ad323&gt;] (dump_stack+0x4f/0x64)
  [&lt;c02ad323&gt;] (dump_stack+0x4f/0x64) from [&lt;c02abe67&gt;] (__schedule_bug+0x37/0x4c)
  [&lt;c02abe67&gt;] (__schedule_bug+0x37/0x4c) from [&lt;c02ae261&gt;] (__schedule+0x325/0x3ec)
  [&lt;c02ae261&gt;] (__schedule+0x325/0x3ec) from [&lt;c02adb97&gt;] (schedule_timeout+0xb7/0x118)
  [&lt;c02adb97&gt;] (schedule_timeout+0xb7/0x118) from [&lt;c0020a67&gt;] (msleep+0xf/0x14)
  [&lt;c0020a67&gt;] (msleep+0xf/0x14) from [&lt;c01dcbe5&gt;] (mvneta_stop_dev+0x21/0x194)
  [&lt;c01dcbe5&gt;] (mvneta_stop_dev+0x21/0x194) from [&lt;c01dcfe9&gt;] (mvneta_tx_timeout+0x19/0x24)
  [&lt;c01dcfe9&gt;] (mvneta_tx_timeout+0x19/0x24) from [&lt;c024afc7&gt;] (dev_watchdog+0x18b/0x1c4)
  [&lt;c024afc7&gt;] (dev_watchdog+0x18b/0x1c4) from [&lt;c0020b53&gt;] (call_timer_fn.isra.27+0x17/0x5c)
  [&lt;c0020b53&gt;] (call_timer_fn.isra.27+0x17/0x5c) from [&lt;c0020cad&gt;] (run_timer_softirq+0x115/0x170)
  [&lt;c0020cad&gt;] (run_timer_softirq+0x115/0x170) from [&lt;c001ccb9&gt;] (__do_softirq+0xbd/0x1a8)
  [&lt;c001ccb9&gt;] (__do_softirq+0xbd/0x1a8) from [&lt;c001cfad&gt;] (irq_exit+0x61/0x98)
  [&lt;c001cfad&gt;] (irq_exit+0x61/0x98) from [&lt;c000d4bf&gt;] (handle_IRQ+0x27/0x60)
  [&lt;c000d4bf&gt;] (handle_IRQ+0x27/0x60) from [&lt;c000843b&gt;] (armada_370_xp_handle_irq+0x33/0xc8)
  [&lt;c000843b&gt;] (armada_370_xp_handle_irq+0x33/0xc8) from [&lt;c000fba9&gt;] (__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 &lt;thomas.petazzoni@free-electrons.com&gt;
Cc: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Tested-by: Arnaud Ebalard &lt;arno@natisbad.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&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>net: mvneta: use per_cpu stats to fix an SMP lock up</title>
<updated>2014-08-07T21:30:27+00:00</updated>
<author>
<name>willy tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2014-01-16T07:20:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=936e9bc5d7f64c98574bb864c4028378f5a01d0c'/>
<id>936e9bc5d7f64c98574bb864c4028378f5a01d0c</id>
<content type='text'>
commit 74c41b048db1073a04827d7f39e95ac1935524cc upstream.

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 &lt;thomas.petazzoni@free-electrons.com&gt;
Cc: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Reviewed-by: Eric Dumazet &lt;edumazet@google.com&gt;
Tested-by: Arnaud Ebalard &lt;arno@natisbad.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[wt: port to 3.10 : u64_stats_init() does not exist in 3.10 and is not needed]
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&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 74c41b048db1073a04827d7f39e95ac1935524cc upstream.

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 &lt;thomas.petazzoni@free-electrons.com&gt;
Cc: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Reviewed-by: Eric Dumazet &lt;edumazet@google.com&gt;
Tested-by: Arnaud Ebalard &lt;arno@natisbad.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[wt: port to 3.10 : u64_stats_init() does not exist in 3.10 and is not needed]
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>net: mvneta: increase the 64-bit rx/tx stats out of the hot path</title>
<updated>2014-08-07T21:30:27+00:00</updated>
<author>
<name>willy tarreau</name>
<email>w@1wt.eu</email>
</author>
<published>2014-01-16T07:20:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5831364f63388662b37b92b2ff6c21a63e82d60d'/>
<id>5831364f63388662b37b92b2ff6c21a63e82d60d</id>
<content type='text'>
commit dc4277dd41a80fd5f29a90412ea04bc3ba54fbf1 upstream.

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 &lt;thomas.petazzoni@free-electrons.com&gt;
Cc: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Reviewed-by: Eric Dumazet &lt;edumazet@google.com&gt;
Tested-by: Arnaud Ebalard &lt;arno@natisbad.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&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 dc4277dd41a80fd5f29a90412ea04bc3ba54fbf1 upstream.

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 &lt;thomas.petazzoni@free-electrons.com&gt;
Cc: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&gt;
Reviewed-by: Eric Dumazet &lt;edumazet@google.com&gt;
Tested-by: Arnaud Ebalard &lt;arno@natisbad.org&gt;
Signed-off-by: Willy Tarreau &lt;w@1wt.eu&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>mwifiex: fix Tx timeout issue</title>
<updated>2014-07-28T15:00:06+00:00</updated>
<author>
<name>Amitkumar Karwar</name>
<email>akarwar@marvell.com</email>
</author>
<published>2014-06-20T18:45:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8503df8d0c177e9e1c5468663b8954205ac069c9'/>
<id>8503df8d0c177e9e1c5468663b8954205ac069c9</id>
<content type='text'>
commit d76744a93246eccdca1106037e8ee29debf48277 upstream.

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

It is observed that sometimes Tx packet is downloaded without
adding driver's txpd header. This results in firmware parsing
garbage data as packet length. Sometimes firmware is unable
to read the packet if length comes out as invalid. This stops
further traffic and timeout occurs.

The root cause is uninitialized fields in tx_info(skb-&gt;cb) of
packet used to get garbage values. In this case if
MWIFIEX_BUF_FLAG_REQUEUED_PKT flag is mistakenly set, txpd
header was skipped. This patch makes sure that tx_info is
correctly initialized to fix the problem.

Reported-by: Andrew Wiley &lt;wiley.andrew.j@gmail.com&gt;
Reported-by: Linus Gasser &lt;list@markas-al-nour.org&gt;
Reported-by: Michael Hirsch &lt;hirsch@teufel.de&gt;
Tested-by: Xinming Hu &lt;huxm@marvell.com&gt;
Signed-off-by: Amitkumar Karwar &lt;akarwar@marvell.com&gt;
Signed-off-by: Maithili Hinge &lt;maithili@marvell.com&gt;
Signed-off-by: Avinash Patil &lt;patila@marvell.com&gt;
Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.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 d76744a93246eccdca1106037e8ee29debf48277 upstream.

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

It is observed that sometimes Tx packet is downloaded without
adding driver's txpd header. This results in firmware parsing
garbage data as packet length. Sometimes firmware is unable
to read the packet if length comes out as invalid. This stops
further traffic and timeout occurs.

The root cause is uninitialized fields in tx_info(skb-&gt;cb) of
packet used to get garbage values. In this case if
MWIFIEX_BUF_FLAG_REQUEUED_PKT flag is mistakenly set, txpd
header was skipped. This patch makes sure that tx_info is
correctly initialized to fix the problem.

Reported-by: Andrew Wiley &lt;wiley.andrew.j@gmail.com&gt;
Reported-by: Linus Gasser &lt;list@markas-al-nour.org&gt;
Reported-by: Michael Hirsch &lt;hirsch@teufel.de&gt;
Tested-by: Xinming Hu &lt;huxm@marvell.com&gt;
Signed-off-by: Amitkumar Karwar &lt;akarwar@marvell.com&gt;
Signed-off-by: Maithili Hinge &lt;maithili@marvell.com&gt;
Signed-off-by: Avinash Patil &lt;patila@marvell.com&gt;
Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>sunvnet: clean up objects created in vnet_new() on vnet_exit()</title>
<updated>2014-07-28T15:00:06+00:00</updated>
<author>
<name>Sowmini Varadhan</name>
<email>sowmini.varadhan@oracle.com</email>
</author>
<published>2014-07-16T14:02:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1c81dac91e065e39413f8ff5d22b444087b0ed11'/>
<id>1c81dac91e065e39413f8ff5d22b444087b0ed11</id>
<content type='text'>
[ Upstream commit a4b70a07ed12a71131cab7adce2ce91c71b37060 ]

Nothing cleans up the objects created by
vnet_new(), they are completely leaked.

vnet_exit(), after doing the vio_unregister_driver() to clean
up ports, should call a helper function that iterates over vnet_list
and cleans up those objects. This includes unregister_netdevice()
as well as free_netdev().

Signed-off-by: Sowmini Varadhan &lt;sowmini.varadhan@oracle.com&gt;
Acked-by: Dave Kleikamp &lt;dave.kleikamp@oracle.com&gt;
Reviewed-by: Karl Volz &lt;karl.volz@oracle.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>
[ Upstream commit a4b70a07ed12a71131cab7adce2ce91c71b37060 ]

Nothing cleans up the objects created by
vnet_new(), they are completely leaked.

vnet_exit(), after doing the vio_unregister_driver() to clean
up ports, should call a helper function that iterates over vnet_list
and cleans up those objects. This includes unregister_netdevice()
as well as free_netdev().

Signed-off-by: Sowmini Varadhan &lt;sowmini.varadhan@oracle.com&gt;
Acked-by: Dave Kleikamp &lt;dave.kleikamp@oracle.com&gt;
Reviewed-by: Karl Volz &lt;karl.volz@oracle.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>
</feed>
