* Re: kernel BUG at net/core/skbuff.c:2839 RIP [<ffffffff819109a2>] skb_segment+0x6b2/0x6d0
From: David Miller @ 2013-11-21 18:38 UTC (permalink / raw)
To: eric.dumazet; +Cc: herbert, linux, edumazet, romieu, netdev
In-Reply-To: <1385058216.10637.53.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 21 Nov 2013 10:23:36 -0800
> I was planning to resend Herbert patch today anyway, after a new round
> of testing on my hosts.
Please do, it would be nice to have your tested-by or similar tag on
it at least.
Thanks!
^ permalink raw reply
* RE: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not ipsec pkt
From: Saurabh Mohan @ 2013-11-21 18:39 UTC (permalink / raw)
To: Fan Du
Cc: Christophe Gouault, Steffen Klassert, David S. Miller, Herbert Xu,
netdev@vger.kernel.org, Sergei Shtylyov, Eric Dumazet
In-Reply-To: <528B2C72.5060809@windriver.com>
> -----Original Message-----
> From: Fan Du [mailto:fan.du@windriver.com]
> Sent: Tuesday, November 19, 2013 1:17 AM
> To: Saurabh Mohan
> Cc: Christophe Gouault; Steffen Klassert; David S. Miller; Herbert Xu;
> netdev@vger.kernel.org; Sergei Shtylyov; Eric Dumazet
> Subject: Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not ipsec
> pkt
>
> Hi, Saurabh
>
> On 2013年11月19日 05:38, Saurabh Mohan wrote:
> >
> >
> >> -----Original Message-----
> >> From: Christophe Gouault [mailto:christophe.gouault@6wind.com]
> >> Sent: Thursday, November 07, 2013 4:56 AM
> >> To: Steffen Klassert
> >> Cc: David S. Miller; Herbert Xu; netdev@vger.kernel.org; Saurabh Mohan;
> >> Sergei Shtylyov; Eric Dumazet
> >> Subject: Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not
> ipsec
> >> pkt
> >>
> >> Hello Steffen,
> >>
> >> I am also interested in knowing Saurabh's intentions regarding the
> >> behavior of policies bound to vti interfaces.
> >>
> > The semantics is to match the policy "src 0.0.0.0/0 dst 0.0.0.0/0 proto any"
> > That is the only policy that VTI should use. The mark is needed to
> > distinguish and limit the policy to a specific vti tunnel interface only.
> > There is no other policy that may be applied to a vti interface.
> > The fact that traffic is going over the tunnel interface implies that it
> > must be encrypted/decrypted. Applying the above policy is a way
> > to achieve that.
>
> I'm not much experienced with VTI usage practical production usage
> scenario, but
> I have one question about the necessity of policy checking on VTI receiving
> part.
> - A VTI tunnel is hashed by destination address and i_key when creating
> them;
> - After each tunneled IP packet delivered to vti_rcv, the first step is looking
> for the right tunnel, this is done by using tunneled IP packet outer source
> and
> destination address without any key matching rule involved.
>
> If there are any other tunnel with the same source/destination address, but
> not
> the same mark in place, the tunnel lookup in the vti_rcv will properly not hit
> VTI tunnel, but the non-VTI tunnel. So the VTI net device statistics will not be
> accurate, and what's the point of checking policy for the wrong tunnel
> interface?
So far this is not supported. If it were needed then we'd have to use another
key on the tunnel(s) to distinguish between tunnel with same src and dst.
In such a case there would be two keys on the tunnel (one for vti mark
and the other one to separate out tunnels with same src and dst).
^ permalink raw reply
* ARM network performance and dma_mask (was: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s)
From: Willy Tarreau @ 2013-11-21 18:38 UTC (permalink / raw)
To: Rob Herring
Cc: Arnaud Ebalard, Thomas Petazzoni, Florian Fainelli, simon.guinot,
Eric Dumazet, netdev, edumazet, Cong Wang, linux-arm-kernel
In-Reply-To: <20131121004430.GX8581@1wt.eu>
Hi Rob,
While we were diagnosing a network performance regression that we finally
found and fixed, it appeared during a test that Linus' tree shows a much
higher performance on Armada 370 (armv7) than its predecessors. I can
saturate the two Gig links of my Mirabox each with a single TCP flow and
keep up to 25% of idle CPU in the optimal case. In 3.12.1 or 3.10.20, I
can achieve around 1.3 Gbps when the two ports are used in parallel.
Today I bisected these kernels to find what was causing this difference.
I found it was your patch below which I can copy entirely here :
commit 0589342c27944e50ebd7a54f5215002b6598b748
Author: Rob Herring <rob.herring@calxeda.com>
Date: Tue Oct 29 23:36:46 2013 -0500
of: set dma_mask to point to coherent_dma_mask
Platform devices created by DT code don't initialize dma_mask pointer to
anything. Set it to coherent_dma_mask by default if the architecture
code has not set it.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 9b439ac..c005495 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -216,6 +216,8 @@ static struct platform_device *of_platform_device_create_pdata(
dev->archdata.dma_mask = 0xffffffffUL;
#endif
dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ if (!dev->dev.dma_mask)
+ dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
dev->dev.bus = &platform_bus_type;
dev->dev.platform_data = platform_data;
And I can confirm that applying this patch on 3.10.20 + the fixes we found
yesterday substantially boosted my network performance (and reduced the CPU
usage when running on a single link).
I'm not at ease with these things so I'd like to ask your opinion here, is
this supposed to be an improvement or a fix ? Is this something we should
backport into stable versions, or is there something to fix in the armada
platform so that it works just as if the patch was applied ?
Thanks,
Willy
^ permalink raw reply
* Re: [PATCH v4 net-next] net: introduce dev_set_forwarding()
From: Eric Dumazet @ 2013-11-21 18:38 UTC (permalink / raw)
To: David Miller
Cc: bhutchings, christoph.paasch, herbert, netdev, hkchu, mwdalton
In-Reply-To: <20131121.132912.1559687338397588769.davem@davemloft.net>
On Thu, 2013-11-21 at 13:29 -0500, David Miller wrote:
> Eric please resubmit this in the future once all of the other fixes
> have been sorted out with Herbert.
Sure, I postponed this for net-next, and will remove the GRO part from
it, as Herbert choked on it ;)
^ permalink raw reply
* Re: [PATCH openvswitch] linux: Signal datapath that unaligned Netlink message can be received
From: Sergei Shtylyov @ 2013-11-21 18:49 UTC (permalink / raw)
To: Thomas Graf, jesse-l0M0P4e3n4LQT0dZR+AlfA
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <48c93fb3c82bca0c9858ff528e2cf79d72d76082.1385057672.git.tgraf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hello.
On 21-11-2013 22:15, Thomas Graf wrote:
> Following commit (''netlink: Do not enforce alignment of last Netlink
> attribute''), signal the ability to receive unaligned Netlink messages
> to the datapath to enable utilization of zerocopy optimizations.
> Signed-off-by: Thomas Graf <tgraf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[...]
> diff --git a/lib/dpif-linux.c b/lib/dpif-linux.c
> index 1dcf321..5c952bc 100644
> --- a/lib/dpif-linux.c
> +++ b/lib/dpif-linux.c
[...]
> @@ -1839,6 +1841,10 @@ dpif_linux_dp_to_ofpbuf(const struct dpif_linux_dp *dp, struct ofpbuf *buf)
> nl_msg_put_u32(buf, OVS_DP_ATTR_UPCALL_PID, *dp->upcall_pid);
> }
>
> + if (dp->user_features) {
> + nl_msg_put_u32(buf, OVS_DP_ATTR_USER_FEATURES, dp->user_features);
> + }
> +
{} not needed here.
WBR, Sergei
^ permalink raw reply
* Re: ARM network performance and dma_mask (was: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s)
From: Thomas Petazzoni @ 2013-11-21 19:04 UTC (permalink / raw)
To: Willy Tarreau
Cc: Rob Herring, Arnaud Ebalard, Florian Fainelli, simon.guinot,
Eric Dumazet, netdev, edumazet, Cong Wang, linux-arm-kernel
In-Reply-To: <20131121183834.GB18513@1wt.eu>
Dear Willy Tarreau,
On Thu, 21 Nov 2013 19:38:34 +0100, Willy Tarreau wrote:
> While we were diagnosing a network performance regression that we finally
> found and fixed, it appeared during a test that Linus' tree shows a much
> higher performance on Armada 370 (armv7) than its predecessors. I can
> saturate the two Gig links of my Mirabox each with a single TCP flow and
> keep up to 25% of idle CPU in the optimal case. In 3.12.1 or 3.10.20, I
> can achieve around 1.3 Gbps when the two ports are used in parallel.
Interesting finding and analysis, once again!
> I'm not at ease with these things so I'd like to ask your opinion here, is
> this supposed to be an improvement or a fix ? Is this something we should
> backport into stable versions, or is there something to fix in the armada
> platform so that it works just as if the patch was applied ?
I guess the driver should have been setting its dma_mask to 0xffffffff,
since the platform is capable of doing DMA on the first 32 bits of the
physical address space, probably something like calling
pci_set_dma_mask(pdev, DMA_BIT_MASK(32)) or something like that. I know
Russell has recently added some helpers to prevent stupid people (like
me) from doing mistakes when setting the DMA masks. Certainly worth
having a look.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] gso: handle new frag_list of frags GRO packets
From: Eric Dumazet @ 2013-11-21 19:10 UTC (permalink / raw)
To: David Miller; +Cc: herbert, linux, edumazet, romieu, netdev
In-Reply-To: <20131121.133824.1318844228024646798.davem@davemloft.net>
From: Herbert Xu <herbert@gondor.apana.org.au>
Recently GRO started generating packets with frag_lists of frags.
This was not handled by GSO, thus leading to a crash.
Thankfully these packets are of a regular form and are easy to
handle. This patch handles them in two ways. For completely
non-linear frag_list entries, we simply continue to iterate over
the frag_list frags once we exhaust the normal frags. For frag_list
entries with linear parts, we call pskb_trim on the first part
of the frag_list skb, and then process the rest of the frags in
the usual way.
This patch also kills a chunk of dead frag_list code that has
obviously never ever been run since it ends up generating a bogus
GSO-segmented packet with a frag_list entry.
Future work is planned to split super big packets into TSO
ones.
Fixes: 8a29111c7ca6 ("net: gro: allow to build full sized skb")
Reported-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Reported-by: Jerry Chu <hkchu@google.com>
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Tested-by: Eric Dumazet <edumazet@google.com>
---
net/core/skbuff.c | 75 +++++++++++++++++++++++++++++---------------
1 file changed, 50 insertions(+), 25 deletions(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 8cec1e6b844d..2718fed53d8c 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2796,6 +2796,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
struct sk_buff *segs = NULL;
struct sk_buff *tail = NULL;
struct sk_buff *fskb = skb_shinfo(skb)->frag_list;
+ skb_frag_t *skb_frag = skb_shinfo(skb)->frags;
unsigned int mss = skb_shinfo(skb)->gso_size;
unsigned int doffset = skb->data - skb_mac_header(skb);
unsigned int offset = doffset;
@@ -2835,16 +2836,38 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
if (hsize > len || !sg)
hsize = len;
- if (!hsize && i >= nfrags) {
- BUG_ON(fskb->len != len);
+ if (!hsize && i >= nfrags && skb_headlen(fskb) &&
+ (skb_headlen(fskb) == len || sg)) {
+ BUG_ON(skb_headlen(fskb) > len);
+
+ i = 0;
+ nfrags = skb_shinfo(fskb)->nr_frags;
+ skb_frag = skb_shinfo(fskb)->frags;
+ pos += skb_headlen(fskb);
+
+ while (pos < offset + len) {
+ BUG_ON(i >= nfrags);
+
+ size = skb_frag_size(skb_frag);
+ if (pos + size > offset + len)
+ break;
+
+ i++;
+ pos += size;
+ skb_frag++;
+ }
- pos += len;
nskb = skb_clone(fskb, GFP_ATOMIC);
fskb = fskb->next;
if (unlikely(!nskb))
goto err;
+ if (unlikely(pskb_trim(nskb, len))) {
+ kfree_skb(nskb);
+ goto err;
+ }
+
hsize = skb_end_offset(nskb);
if (skb_cow_head(nskb, doffset + headroom)) {
kfree_skb(nskb);
@@ -2881,7 +2904,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
nskb->data - tnl_hlen,
doffset + tnl_hlen);
- if (fskb != skb_shinfo(skb)->frag_list)
+ if (nskb->len == len + doffset)
goto perform_csum_check;
if (!sg) {
@@ -2899,8 +2922,28 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
skb_shinfo(nskb)->tx_flags = skb_shinfo(skb)->tx_flags & SKBTX_SHARED_FRAG;
- while (pos < offset + len && i < nfrags) {
- *frag = skb_shinfo(skb)->frags[i];
+ while (pos < offset + len) {
+ if (i >= nfrags) {
+ BUG_ON(skb_headlen(fskb));
+
+ i = 0;
+ nfrags = skb_shinfo(fskb)->nr_frags;
+ skb_frag = skb_shinfo(fskb)->frags;
+
+ BUG_ON(!nfrags);
+
+ fskb = fskb->next;
+ }
+
+ if (unlikely(skb_shinfo(nskb)->nr_frags >=
+ MAX_SKB_FRAGS)) {
+ net_warn_ratelimited(
+ "skb_segment: too many frags: %u %u\n",
+ pos, mss);
+ goto err;
+ }
+
+ *frag = *skb_frag;
__skb_frag_ref(frag);
size = skb_frag_size(frag);
@@ -2913,6 +2956,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
if (pos + size <= offset + len) {
i++;
+ skb_frag++;
pos += size;
} else {
skb_frag_size_sub(frag, pos + size - (offset + len));
@@ -2922,25 +2966,6 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
frag++;
}
- if (pos < offset + len) {
- struct sk_buff *fskb2 = fskb;
-
- BUG_ON(pos + fskb->len != offset + len);
-
- pos += fskb->len;
- fskb = fskb->next;
-
- if (fskb2->next) {
- fskb2 = skb_clone(fskb2, GFP_ATOMIC);
- if (!fskb2)
- goto err;
- } else
- skb_get(fskb2);
-
- SKB_FRAG_ASSERT(nskb);
- skb_shinfo(nskb)->frag_list = fskb2;
- }
-
skip_fraglist:
nskb->data_len = len - hsize;
nskb->len += nskb->data_len;
^ permalink raw reply related
* Re: [PATCH v2] gso: handle new frag_list of frags GRO packets
From: David Miller @ 2013-11-21 19:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: herbert, linux, edumazet, romieu, netdev
In-Reply-To: <1385061004.10637.64.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 21 Nov 2013 11:10:04 -0800
> From: Herbert Xu <herbert@gondor.apana.org.au>
>
> Recently GRO started generating packets with frag_lists of frags.
> This was not handled by GSO, thus leading to a crash.
>
> Thankfully these packets are of a regular form and are easy to
> handle. This patch handles them in two ways. For completely
> non-linear frag_list entries, we simply continue to iterate over
> the frag_list frags once we exhaust the normal frags. For frag_list
> entries with linear parts, we call pskb_trim on the first part
> of the frag_list skb, and then process the rest of the frags in
> the usual way.
>
> This patch also kills a chunk of dead frag_list code that has
> obviously never ever been run since it ends up generating a bogus
> GSO-segmented packet with a frag_list entry.
>
> Future work is planned to split super big packets into TSO
> ones.
>
> Fixes: 8a29111c7ca6 ("net: gro: allow to build full sized skb")
> Reported-by: Christoph Paasch <christoph.paasch@uclouvain.be>
> Reported-by: Jerry Chu <hkchu@google.com>
> Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
> Tested-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for 3.12-stable, thanks!
^ permalink raw reply
* Re: [RFC] wireless, ipv4, ipv6: drop GTK-protected unicast IP packets
From: David Miller @ 2013-11-21 19:14 UTC (permalink / raw)
To: johannes; +Cc: eric.dumazet, linux-wireless, netdev, jouni
In-Reply-To: <1385044264.14273.6.camel@jlt4.sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 21 Nov 2013 15:31:04 +0100
> Yeah, that was a concern too. I'll do it entirely in the wireless stack
> instead I guess. At least it'll be hidden away inside the if that
> already does the group key check etc.
I agree that you should try to take care of this in the wireless
stack.
^ permalink raw reply
* Re: [PATCH net] neigh: Force garbage collection if an entry is deleted administratively
From: David Miller @ 2013-11-21 19:18 UTC (permalink / raw)
To: steffen.klassert; +Cc: David.Laight, yoshfuji, netdev
In-Reply-To: <20131119124102.GA31491@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Tue, 19 Nov 2013 13:41:02 +0100
> We have the table locked in neigh_periodic_work() so we can unlink
> invalidated entries there. This function could then periodically
> check and remove the unlinked entries if they lost their references.
> Unlinking with neigh_periodic_work() would have some seconds delay
> of course, but I think this is acceptable.
Create an "invalidated_list", and at the moment the neigh is
administratively deleted you can remove it from the hash table and
link it into this new list.
Then neigh_periodic_work() can scan both the hash tables and this
"invalidated_list" for refcnt==1 entries.
It seems a good solution, and should avoid the need to handle
forcibly freeing a neigh which still has external references.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2013-11-21 19:26 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix memory leaks and other issues in mwifiex driver, from Amitkumar
Karwar.
2) skb_segment() can choke on packets using frag lists, fix from
Herbert Xu with help from Eric Dumazet and others.
3) IPv4 output cached route instantiation properly handles races
involving two threads trying to install the same route, but we
forgot to propagate this logic to input routes as well. Fix
from Alexei Starovoitov.
4) Put protections in place to make sure that recvmsg() paths never
accidently copy uninitialized memory back into userspace and also
make sure that we never try to use more that sockaddr_storage for
building the on-kernel-stack copy of a sockaddr. Fixes from Hannes
Frederic Sowa.
5) R8152 driver transmit flow bug fixes from Hayes Wang.
6) Fix some minor fallouts from genetlink changes, from Johannes Berg
and Michael Opdenacker.
7) AF_PACKET sendmsg path can race with netdevice unregister notifier,
fix by using RCU to make sure the network device doesn't go away
from under us. Fix from Daniel Borkmann.
Please pull, thanks a lot!
The following changes since commit b4789b8e6be3151a955ade74872822f30e8cd914:
aacraid: prevent invalid pointer dereference (2013-11-19 16:27:39 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
for you to fetch changes up to 9d8506cc2d7ea1f911c72c100193a3677f6668c3:
gso: handle new frag_list of frags GRO packets (2013-11-21 14:11:50 -0500)
----------------------------------------------------------------
Alexei Starovoitov (1):
ipv4: fix race in concurrent ip_route_input_slow()
Amitkumar Karwar (5):
mwifiex: use return value of mwifiex_add_virtual_intf() correctly
mwifiex: failure path handling in mwifiex_add_virtual_intf()
mwifiex: fix NULL pointer dereference in mwifiex_fw_dpc
mwifiex: fix potential mem leak in .del_virtual_intf
mwifiex: fix memory leak issue for sdio and pcie cards
Andy Fleming (1):
net/phy: Add VSC8234 support
Daniel Borkmann (1):
packet: fix use after free race in send path when dev is released
David S. Miller (3):
Merge branch 'r8152'
Merge branch 'master' of git://git.kernel.org/.../pablo/nf
Merge branch 'for-davem' of git://git.kernel.org/.../linville/wireless
David Vrabel (1):
xen-netback: stop the VIF thread before unbinding IRQs
Ding Tianhong (1):
bridge: flush br's address entry in fdb when remove the
Felix Fietkau (1):
rt2x00: fix a crash bug in the HT descriptor handling fix
Geyslan G. Bem (1):
brcmfmac: fix possible memory leak
Hannes Frederic Sowa (2):
net: rework recvmsg handler msg_name and msg_namelen logic
net: add BUG_ON if kernel advertises msg_namelen > sizeof(struct sockaddr_storage)
Herbert Xu (1):
gso: handle new frag_list of frags GRO packets
Johan Hedberg (1):
Bluetooth: Fix rejecting SMP security request in slave role
Johannes Berg (2):
genetlink: fix genlmsg_multicast() bug
genetlink: fix genl_set_err() group ID
John W. Linville (2):
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Larry Finger (1):
rtlwifi: rtl8192cu: Fix more pointer arithmetic errors
Luis R. Rodriguez (1):
ath: fix dynamic user regulatory settings
Luís Fernando Cornachioni Estrozi (1):
netfilter: ebt_ip6: fix source and destination matching
Madalin Bucur (1):
net/phy: Add the autocross feature for forced links on VSC82x4
Marcel Holtmann (1):
Bluetooth: Fix issue with RFCOMM getsockopt operation
Martin Topholm (2):
netfilter: synproxy: send mss option to backend
netfilter: synproxy: correct wscale option passing
Michael Opdenacker (1):
wimax: remove dead code
Pablo Neira Ayuso (2):
netfilter: nft_compat: fix error path in nft_parse_compat()
netfilter: nf_conntrack: decrement global counter after object release
Phil Oester (1):
netfilter: fix wrong byte order in nf_ct_seqadj_set internal information
Randy Dunlap (1):
netfilter: fix connlimit Kconfig prompt string
Sandeep Singh (1):
net/phy: Add VSC8662 support
Seung-Woo Kim (3):
Bluetooth: Fix RFCOMM bind fail for L2CAP sock
Bluetooth: Fix to set proper bdaddr_type for RFCOMM connect
Bluetooth: Fix crash in l2cap_chan_send after l2cap_chan_del
Sujith Manoharan (2):
ath9k: Update AR9462 2.1 initvals
ath9k: Fix issue with MCS15
Ujjal Roy (1):
mwifiex: fix issues in driver unload path for USB chipsets
Vlad Yasevich (1):
net: core: Always propagate flag changes to interfaces
hayeswang (4):
r8152: fix tx/rx memory overflow
r8152: modify the tx flow
r8152: support stopping/waking tx queue
r8152: fix incorrect type in assignment
shaohui xie (1):
net/phy: Add VSC8574 support
crypto/algif_hash.c | 2 -
crypto/algif_skcipher.c | 1 -
drivers/isdn/mISDN/socket.c | 13 ++-----
drivers/net/phy/phy_device.c | 4 +-
drivers/net/phy/vitesse.c | 117 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
drivers/net/ppp/pppoe.c | 2 -
drivers/net/usb/r8152.c | 114 +++++++++++++++++++++++++-------------------------------
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 50 +++++++++++++++++++++++++
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 11 ++++++
drivers/net/wireless/ath/ath9k/ar9462_2p1_initvals.h | 6 +--
drivers/net/wireless/ath/regd.c | 3 +-
drivers/net/wireless/brcm80211/brcmfmac/p2p.c | 1 +
drivers/net/wireless/mwifiex/cfg80211.c | 23 ++++++++++--
drivers/net/wireless/mwifiex/main.c | 28 ++++----------
drivers/net/wireless/mwifiex/pcie.c | 2 +-
drivers/net/wireless/mwifiex/sdio.c | 7 ++--
drivers/net/wireless/mwifiex/usb.c | 27 ++++++++------
drivers/net/wireless/rt2x00/rt2x00dev.c | 3 +-
drivers/net/wireless/rtlwifi/rtl8192cu/mac.c | 6 +--
drivers/net/wireless/rtlwifi/rtl8192cu/trx.c | 6 +--
drivers/net/xen-netback/interface.c | 6 +--
include/linux/net.h | 8 ++++
include/linux/phy.h | 1 +
include/net/genetlink.h | 8 ++--
net/appletalk/ddp.c | 16 ++++----
net/atm/common.c | 2 -
net/ax25/af_ax25.c | 4 +-
net/bluetooth/af_bluetooth.c | 9 +----
net/bluetooth/hci_sock.c | 2 -
net/bluetooth/l2cap_core.c | 3 ++
net/bluetooth/rfcomm/core.c | 3 ++
net/bluetooth/rfcomm/sock.c | 7 +++-
net/bluetooth/sco.c | 1 -
net/bluetooth/smp.c | 3 ++
net/bridge/br_if.c | 2 +
net/bridge/netfilter/ebt_ip6.c | 8 ++--
net/caif/caif_socket.c | 4 --
net/compat.c | 3 +-
net/core/dev.c | 2 +-
net/core/iovec.c | 3 +-
net/core/skbuff.c | 75 ++++++++++++++++++++++++-------------
net/ipv4/netfilter/ipt_SYNPROXY.c | 1 +
net/ipv4/route.c | 8 +++-
net/ipv6/netfilter/ip6t_SYNPROXY.c | 1 +
net/ipx/af_ipx.c | 3 +-
net/irda/af_irda.c | 4 --
net/iucv/af_iucv.c | 2 -
net/key/af_key.c | 1 -
net/l2tp/l2tp_ppp.c | 2 -
net/llc/af_llc.c | 2 -
net/netfilter/Kconfig | 2 +-
net/netfilter/nf_conntrack_core.c | 3 +-
net/netfilter/nf_conntrack_seqadj.c | 4 +-
net/netfilter/nf_synproxy_core.c | 7 ++--
net/netfilter/nft_compat.c | 19 +++++++---
net/netlink/af_netlink.c | 2 -
net/netlink/genetlink.c | 4 +-
net/netrom/af_netrom.c | 3 +-
net/nfc/llcp_sock.c | 2 -
net/nfc/rawsock.c | 2 -
net/packet/af_packet.c | 91 +++++++++++++++++++++++++--------------------
net/packet/internal.h | 1 +
net/rds/recv.c | 2 -
net/rose/af_rose.c | 8 ++--
net/rxrpc/ar-recvmsg.c | 9 +++--
net/socket.c | 22 ++++++-----
net/tipc/socket.c | 6 ---
net/unix/af_unix.c | 5 ---
net/vmw_vsock/af_vsock.c | 2 -
net/vmw_vsock/vmci_transport.c | 2 -
net/wimax/stack.c | 1 -
net/x25/af_x25.c | 3 +-
72 files changed, 504 insertions(+), 316 deletions(-)
^ permalink raw reply
* Re: [PATCH 0/4] Add ceph root filesystem functionality and documentation.
From: David Dillow @ 2013-11-21 20:19 UTC (permalink / raw)
To: mark.doffman
Cc: ceph-devel, sage, netdev, linux-kernel, linux-nfs, rob.taylor
In-Reply-To: <1385000024-23463-1-git-send-email-mark.doffman@codethink.co.uk>
On Wed, 2013-11-20 at 20:13 -0600, mark.doffman@codethink.co.uk wrote:
> The following patch series adds the ability to use a ceph distributed
> file system as the root device. The functionality is similar to
> NFS root but for the ceph filesystem.
Why do this in the kernel vs in the initramfs? Dracut would be a more
appropriate place, I think, as it has support for other network root
devices already.
^ permalink raw reply
* Re: [PATCH] bonding: If IP route look-up to send an ARP fails, mark in bonding structure as no ARP sent.
From: rama nichanamatlu @ 2013-11-21 20:34 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: netdev
In-Reply-To: <20131121111022.GA30998@redhat.com>
On 11/21/2013 3:10 AM, Veaceslav Falico wrote:
> On Wed, Nov 20, 2013 at 04:53:20PM -0800, rama nichanamatlu wrote:
>> During the creation of VLAN's atop bonding the underlying interfaces
>> are made part of VLAN's, and at the same bonding driver gets aware
>> that VLAN's exists above it and hence would consult IP routing for
>> every ARP to be sent to determine the route which tells bonding
>> driver the correct VLAN tag to attach to the outgoing ARP packet. But,
>> during the VLAN creation when vlan driver puts the underlying
>> interface into default vlan and then actual vlan, in-between this if
>> bonding driver consults the IP for a route, IP fails to provide a
>> correct route and upon which bonding driver drops the ARP packet. ARP
>> monitor when it
>> comes around next time, sees no ARP response and fails-over to the
>> next available slave. Consulting for a IP route,
>> ip_route_output(),happens in bond_arp_send_all().
>
> bonding works as expected - nothing to fix here. And even as a
> workaround/hack - I'm not sure we need that to suppress one failover *only*
> when vlan is added on top.
>
>>
Thank U.
With *out* this change our systems failed system testing, to
consistently be on designated primary interface on *every* single
reboot. With this change the behavior was as expected even after a few
thousand reboots & System testing could move to next level catching an
another bug in sr-iov :). And Without, the outcome was less predictable
after a reboot and bonding was on a different slave each time.
-Rama
>> To prevent this false fail-over, when bonding driver fails to send an
>> ARP out it marks in its private structure, bonding{}, not to expect
>> an ARP response, when ARP monitor comes around next time ARP sending
>> will be tried again.
>>
>> Extensively tested in a VM environment; sr-iov intf->bonding
>> intf->vlan intf. All virtual interfaces created at boot time.
>>
^ permalink raw reply
* Re: [PATCH openvswitch] linux: Signal datapath that unaligned Netlink message can be received
From: Ben Pfaff @ 2013-11-21 20:52 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <528E559C.4020201-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On Thu, Nov 21, 2013 at 10:49:00PM +0400, Sergei Shtylyov wrote:
> On 21-11-2013 22:15, Thomas Graf wrote:
>
> >Following commit (''netlink: Do not enforce alignment of last Netlink
> >attribute''), signal the ability to receive unaligned Netlink messages
> >to the datapath to enable utilization of zerocopy optimizations.
>
> >Signed-off-by: Thomas Graf <tgraf-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> [...]
>
> >diff --git a/lib/dpif-linux.c b/lib/dpif-linux.c
> >index 1dcf321..5c952bc 100644
> >--- a/lib/dpif-linux.c
> >+++ b/lib/dpif-linux.c
> [...]
> >@@ -1839,6 +1841,10 @@ dpif_linux_dp_to_ofpbuf(const struct dpif_linux_dp *dp, struct ofpbuf *buf)
> > nl_msg_put_u32(buf, OVS_DP_ATTR_UPCALL_PID, *dp->upcall_pid);
> > }
> >
> >+ if (dp->user_features) {
> >+ nl_msg_put_u32(buf, OVS_DP_ATTR_USER_FEATURES, dp->user_features);
> >+ }
> >+
>
> {} not needed here.
This is Open vSwitch code, so it follows Open vSwitch coding style,
which requires the {}.
^ permalink raw reply
* Re: [PATCH] bonding: If IP route look-up to send an ARP fails, mark in bonding structure as no ARP sent.
From: Jay Vosburgh @ 2013-11-21 21:12 UTC (permalink / raw)
To: rama nichanamatlu; +Cc: Veaceslav Falico, netdev
In-Reply-To: <528E6E40.6020201@oracle.com>
rama nichanamatlu <rama.nichanamatlu@oracle.com> wrote:
>On 11/21/2013 3:10 AM, Veaceslav Falico wrote:
>> On Wed, Nov 20, 2013 at 04:53:20PM -0800, rama nichanamatlu wrote:
>>> During the creation of VLAN's atop bonding the underlying interfaces
>>> are made part of VLAN's, and at the same bonding driver gets aware
>>> that VLAN's exists above it and hence would consult IP routing for
>>> every ARP to be sent to determine the route which tells bonding
>>> driver the correct VLAN tag to attach to the outgoing ARP packet. But,
>>> during the VLAN creation when vlan driver puts the underlying
>>> interface into default vlan and then actual vlan, in-between this if
>>> bonding driver consults the IP for a route, IP fails to provide a
>>> correct route and upon which bonding driver drops the ARP packet. ARP
>>> monitor when it
>>> comes around next time, sees no ARP response and fails-over to the
>>> next available slave. Consulting for a IP route,
>>> ip_route_output(),happens in bond_arp_send_all().
>>
>> bonding works as expected - nothing to fix here. And even as a
>> workaround/hack - I'm not sure we need that to suppress one failover *only*
>> when vlan is added on top.
>>
>>>
>Thank U.
>With *out* this change our systems failed system testing, to
>consistently be on designated primary interface on *every* single
>reboot. With this change the behavior was as expected even after a few
>thousand reboots & System testing could move to next level catching an
>another bug in sr-iov :). And Without, the outcome was less predictable
>after a reboot and bonding was on a different slave each time.
>-Rama
By "designated primary" you mean the bonding primary option,
correct? If not, does setting primary resolve the problem? If so,
you're saying that during the bringup, bonding would end up with a
non-primary slave as the active slave? Or that there would be a
failover / failback cycle during the bringup due to the lack of VLAN
availability?
There is already a mechanism in bond_ab_arp_inspect() to give
new slaves a grace period before applying link failures:
/*
* Give slaves 2*delta after being enslaved or made
* active. This avoids bouncing, as the last receive
* times need a full ARP monitor cycle to be updated.
*/
if (bond_time_in_interval(bond, slave->jiffies, 2))
continue;
If you extend that grace period (the "2", which is in units of
the arp_interval), does the problem resolve itself, or is the time
window here longer than that?
How is the configuration of bonding and the VLANs taking place?
I don't think this patch is suitable (because it can mask
legitimate failures), but I'm not entirely sure I understand the details
of the problem. Is this simply that the arp_ip_target is specified as a
VLAN destination signficantly before (meaning perhaps many seconds of
real time) the VLAN is configured above bonding, or is it some kind of
race condition in the VLAN code?
-J
>>> To prevent this false fail-over, when bonding driver fails to send an
>>> ARP out it marks in its private structure, bonding{}, not to expect
>>> an ARP response, when ARP monitor comes around next time ARP sending
>>> will be tried again.
>>>
>>> Extensively tested in a VM environment; sr-iov intf->bonding
>>> intf->vlan intf. All virtual interfaces created at boot time.
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
From: Arnaud Ebalard @ 2013-11-21 21:51 UTC (permalink / raw)
To: Willy Tarreau
Cc: Thomas Petazzoni, Florian Fainelli, simon.guinot, Eric Dumazet,
netdev, edumazet, Cong Wang, linux-arm-kernel
In-Reply-To: <20131121004430.GX8581@1wt.eu>
Hi,
Willy Tarreau <w@1wt.eu> writes:
> OK it paid off. And very well :-)
>
> I did it at once and it worked immediately. I generally don't like this
> because I always fear that some bug was left there hidden in the code. I have
> only tested it on the Mirabox, so I'll have to try on the OpenBlocks AX3-4 and
> on the XP-GP board for some SMP stress tests.
>
> I upgraded my Mirabox to latest Linus' git (commit 5527d151) and compared
> with and without the patch.
>
> without :
> - need at least 12 streams to reach gigabit.
> - 60% of idle CPU remains at 1 Gbps
> - HTTP connection rate on empty objects is 9950 connections/s
> - cumulated outgoing traffic on two ports reaches 1.3 Gbps
>
> with the patch :
> - a single stream easily saturates the gigabit
> - 87% of idle CPU at 1 Gbps (12 streams, 90% idle at 1 stream)
> - HTTP connection rate on empty objects is 10250 connections/s
> - I saturate the two gig ports at 99% CPU, so 2 Gbps sustained output.
>
> BTW I must say I was impressed to see that big an improvement in CPU
> usage between 3.10 and 3.13, I suspect some of the Tx queue improvements
> that Eric has done in between account for this.
>
> I cut the patch in 3 parts :
> - one which reintroduces the hidden bits of the driver
> - one which replaces the timer with the IRQ
> - one which changes the default Tx coalesce from 16 to 4 packets
> (larger was preferred with the timer, but less is better now).
>
> I'm attaching them, please test them on your device.
Well, on the RN102 (Armada 370), I get the same results as with your
previous patch, i.e. netperf and nginx saturate the link. Apache still
lagging behind though.
> Note that this is *not* for inclusion at the moment as it has not been
> tested on the SMP CPUs.
I tested it on my RN2120 (2-core armada XP): I got no problem and the
link saturated w/ apache, nginx and netperf. Good work!
Cheers,
a+
^ permalink raw reply
* Re: ARM network performance and dma_mask (was: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s)
From: Willy Tarreau @ 2013-11-21 21:51 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Florian Fainelli, simon.guinot, Eric Dumazet, netdev,
Arnaud Ebalard, Rob Herring, edumazet, Cong Wang,
linux-arm-kernel
In-Reply-To: <20131121200433.4cb97d9e@skate>
Hi Thomas,
On Thu, Nov 21, 2013 at 08:04:33PM +0100, Thomas Petazzoni wrote:
> > I'm not at ease with these things so I'd like to ask your opinion here, is
> > this supposed to be an improvement or a fix ? Is this something we should
> > backport into stable versions, or is there something to fix in the armada
> > platform so that it works just as if the patch was applied ?
>
> I guess the driver should have been setting its dma_mask to 0xffffffff,
> since the platform is capable of doing DMA on the first 32 bits of the
> physical address space, probably something like calling
> pci_set_dma_mask(pdev, DMA_BIT_MASK(32)) or something like that.
Almost, yes. Thanks for the tip! There are so few drivers which do this
that I was convinced something was missing (nobody initializes dma_mask
on this platform), so calls to dma_set_mask() from drivers return -EIO
and are ignored.
I ended up with that in mvneta_init() at the end :
/* setting DMA mask significantly improves transfer rates */
pp->dev->dev.parent->coherent_dma_mask = DMA_BIT_MASK(32);
pp->dev->dev.parent->dma_mask = &pp->dev->dev.parent->coherent_dma_mask;
This method changed in 3.12 with Russell's commit fa6a8d6 (DMA-API: provide
a helper to setup DMA masks) doing it a cleaner and safer way, using
dma_coerce_mask_and_coherent().
Then Rob's commit 0589342 (of: set dma_mask to point to coherent_dma_mask) also
merged in 3.12 pre-initialized the dma_mask to point to &coherent_dma_mask for
all devices by default.
> I know
> Russell has recently added some helpers to prevent stupid people (like
> me) from doing mistakes when setting the DMA masks. Certainly worth
> having a look.
My change now allows me to proxy HTTP traffic at 1 Gbps between the two
ports of the mirabox, while it limits to 650 Mbps without the change. But
it's not needed in mainline anymore. However it might be worth having in
older kernels (I don't know if it's suitable for stable since I don't
know if that's a bug), or at least in your own kernels if you have to
maintain and older branch for some customers.
That said, I tend to believe that applying Rob's patch will be better than
just the change above since it will cover all drivers, not only mvneta.
I'll have to test on the AX3 and the XP-GP to see the performance gain in
SMP and using the PCIe.
Best regards,
Willy
^ permalink raw reply
* Re: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
From: Willy Tarreau @ 2013-11-21 21:52 UTC (permalink / raw)
To: Arnaud Ebalard
Cc: Thomas Petazzoni, Florian Fainelli, simon.guinot, Eric Dumazet,
netdev, edumazet, Cong Wang, linux-arm-kernel
In-Reply-To: <871u298lv6.fsf@natisbad.org>
On Thu, Nov 21, 2013 at 10:51:09PM +0100, Arnaud Ebalard wrote:
> Hi,
>
> Willy Tarreau <w@1wt.eu> writes:
>
> > OK it paid off. And very well :-)
> >
> > I did it at once and it worked immediately. I generally don't like this
> > because I always fear that some bug was left there hidden in the code. I have
> > only tested it on the Mirabox, so I'll have to try on the OpenBlocks AX3-4 and
> > on the XP-GP board for some SMP stress tests.
> >
> > I upgraded my Mirabox to latest Linus' git (commit 5527d151) and compared
> > with and without the patch.
> >
> > without :
> > - need at least 12 streams to reach gigabit.
> > - 60% of idle CPU remains at 1 Gbps
> > - HTTP connection rate on empty objects is 9950 connections/s
> > - cumulated outgoing traffic on two ports reaches 1.3 Gbps
> >
> > with the patch :
> > - a single stream easily saturates the gigabit
> > - 87% of idle CPU at 1 Gbps (12 streams, 90% idle at 1 stream)
> > - HTTP connection rate on empty objects is 10250 connections/s
> > - I saturate the two gig ports at 99% CPU, so 2 Gbps sustained output.
> >
> > BTW I must say I was impressed to see that big an improvement in CPU
> > usage between 3.10 and 3.13, I suspect some of the Tx queue improvements
> > that Eric has done in between account for this.
> >
> > I cut the patch in 3 parts :
> > - one which reintroduces the hidden bits of the driver
> > - one which replaces the timer with the IRQ
> > - one which changes the default Tx coalesce from 16 to 4 packets
> > (larger was preferred with the timer, but less is better now).
> >
> > I'm attaching them, please test them on your device.
>
> Well, on the RN102 (Armada 370), I get the same results as with your
> previous patch, i.e. netperf and nginx saturate the link. Apache still
> lagging behind though.
>
> > Note that this is *not* for inclusion at the moment as it has not been
> > tested on the SMP CPUs.
>
> I tested it on my RN2120 (2-core armada XP): I got no problem and the
> link saturated w/ apache, nginx and netperf. Good work!
Great, thanks for your tests Arnaud. I forgot to mention that all my
tests this evening involved this patch as well.
Cheers,
Willy
^ permalink raw reply
* [PATCH] net: sctp: find the correct highest_new_tsn in sack
From: Chang Xiangzhong @ 2013-11-21 21:56 UTC (permalink / raw)
To: vyasevich, nhorman, davem
Cc: linux-sctp, netdev, linux-kernel, Chang Xiangzhong
Function sctp_check_transmitted(transport t, ...) would iterate all of
transport->transmitted queue and looking for the highest __newly__ acked tsn.
The original algorithm would depend on the order of the assoc->transport_list
(in function sctp_outq_sack line 1215 - 1226). The result might not be the
expected due to the order of the tranport_list.
Solution: checking if the exising is smaller than the new one before assigning
Signed-off-by: Chang Xiangzhong <changxiangzhong@gmail.com>
---
net/sctp/outqueue.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
index ef9e2bb..1b494fa 100644
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -1397,7 +1397,8 @@ static void sctp_check_transmitted(struct sctp_outq *q,
*/
if (!tchunk->tsn_gap_acked) {
tchunk->tsn_gap_acked = 1;
- *highest_new_tsn_in_sack = tsn;
+ if (TSN_lt(*highest_new_tsn_in_sack, tsn))
+ *highest_new_tsn_in_sack = tsn;
bytes_acked += sctp_data_size(tchunk);
if (!tchunk->transport)
migrate_bytes += sctp_data_size(tchunk);
--
1.8.4.3
^ permalink raw reply related
* Re: [BUG,REGRESSION?] 3.11.6+,3.12: GbE iface rate drops to few KB/s
From: Eric Dumazet @ 2013-11-21 22:00 UTC (permalink / raw)
To: Willy Tarreau
Cc: Arnaud Ebalard, Thomas Petazzoni, Florian Fainelli, simon.guinot,
netdev, edumazet, Cong Wang, linux-arm-kernel
In-Reply-To: <20131121215259.GE18513@1wt.eu>
On Thu, 2013-11-21 at 22:52 +0100, Willy Tarreau wrote:
> On Thu, Nov 21, 2013 at 10:51:09PM +0100, Arnaud Ebalard wrote:
> > Hi,
> >
> > Willy Tarreau <w@1wt.eu> writes:
> >
> > > OK it paid off. And very well :-)
> > >
> > > I did it at once and it worked immediately. I generally don't like this
> > > because I always fear that some bug was left there hidden in the code. I have
> > > only tested it on the Mirabox, so I'll have to try on the OpenBlocks AX3-4 and
> > > on the XP-GP board for some SMP stress tests.
> > >
> > > I upgraded my Mirabox to latest Linus' git (commit 5527d151) and compared
> > > with and without the patch.
> > >
> > > without :
> > > - need at least 12 streams to reach gigabit.
> > > - 60% of idle CPU remains at 1 Gbps
> > > - HTTP connection rate on empty objects is 9950 connections/s
> > > - cumulated outgoing traffic on two ports reaches 1.3 Gbps
> > >
> > > with the patch :
> > > - a single stream easily saturates the gigabit
> > > - 87% of idle CPU at 1 Gbps (12 streams, 90% idle at 1 stream)
> > > - HTTP connection rate on empty objects is 10250 connections/s
> > > - I saturate the two gig ports at 99% CPU, so 2 Gbps sustained output.
> > >
> > > BTW I must say I was impressed to see that big an improvement in CPU
> > > usage between 3.10 and 3.13, I suspect some of the Tx queue improvements
> > > that Eric has done in between account for this.
> > >
> > > I cut the patch in 3 parts :
> > > - one which reintroduces the hidden bits of the driver
> > > - one which replaces the timer with the IRQ
> > > - one which changes the default Tx coalesce from 16 to 4 packets
> > > (larger was preferred with the timer, but less is better now).
> > >
> > > I'm attaching them, please test them on your device.
> >
> > Well, on the RN102 (Armada 370), I get the same results as with your
> > previous patch, i.e. netperf and nginx saturate the link. Apache still
> > lagging behind though.
> >
> > > Note that this is *not* for inclusion at the moment as it has not been
> > > tested on the SMP CPUs.
> >
> > I tested it on my RN2120 (2-core armada XP): I got no problem and the
> > link saturated w/ apache, nginx and netperf. Good work!
>
> Great, thanks for your tests Arnaud. I forgot to mention that all my
> tests this evening involved this patch as well.
Now you might try to set a lower value
for /proc/sys/net/ipv4/tcp_limit_output_bytes
Ideally, a value of 8192 (instead of 131072) allows
to queue less data per tcp flow, and react faster to losses,
as retransmits don't have to wait that previous packets in Qdisc left
the host.
131072 bytes for a 80 Mbit flow means more than 11 ms of queueing :(
^ permalink raw reply
* Re: ARM network performance and dma_mask
From: Rob Herring @ 2013-11-21 22:01 UTC (permalink / raw)
To: Willy Tarreau
Cc: Arnaud Ebalard, Thomas Petazzoni, Florian Fainelli, simon.guinot,
Eric Dumazet, netdev, edumazet, Cong Wang, linux-arm-kernel
In-Reply-To: <20131121183834.GB18513@1wt.eu>
On 11/21/2013 12:38 PM, Willy Tarreau wrote:
> Hi Rob,
>
> While we were diagnosing a network performance regression that we finally
> found and fixed, it appeared during a test that Linus' tree shows a much
> higher performance on Armada 370 (armv7) than its predecessors. I can
> saturate the two Gig links of my Mirabox each with a single TCP flow and
> keep up to 25% of idle CPU in the optimal case. In 3.12.1 or 3.10.20, I
> can achieve around 1.3 Gbps when the two ports are used in parallel.
>
> Today I bisected these kernels to find what was causing this difference.
> I found it was your patch below which I can copy entirely here :
>
> commit 0589342c27944e50ebd7a54f5215002b6598b748
> Author: Rob Herring <rob.herring@calxeda.com>
> Date: Tue Oct 29 23:36:46 2013 -0500
>
> of: set dma_mask to point to coherent_dma_mask
>
> Platform devices created by DT code don't initialize dma_mask pointer to
> anything. Set it to coherent_dma_mask by default if the architecture
> code has not set it.
>
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 9b439ac..c005495 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -216,6 +216,8 @@ static struct platform_device *of_platform_device_create_pdata(
> dev->archdata.dma_mask = 0xffffffffUL;
> #endif
> dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + if (!dev->dev.dma_mask)
> + dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
> dev->dev.bus = &platform_bus_type;
> dev->dev.platform_data = platform_data;
>
> And I can confirm that applying this patch on 3.10.20 + the fixes we found
> yesterday substantially boosted my network performance (and reduced the CPU
> usage when running on a single link).
>
> I'm not at ease with these things so I'd like to ask your opinion here, is
> this supposed to be an improvement or a fix ? Is this something we should
> backport into stable versions, or is there something to fix in the armada
> platform so that it works just as if the patch was applied ?
>
The patch was to fix this issue[1]. It is fixed in the core code because
dma_mask not being set has been a known issue with DT probing for some
time. Since most drivers don't seem to care, we've gotten away with it.
I thought the normal failure mode was drivers failing to probe.
As to why it helps performance, I'm not really sure. Perhaps it is
causing some bounce buffers to be used.
Rob
[1] http://lists.xen.org/archives/html/xen-devel/2013-10/msg00092.html
^ permalink raw reply
* Re: ARM network performance and dma_mask
From: Willy Tarreau @ 2013-11-21 22:13 UTC (permalink / raw)
To: Rob Herring
Cc: Arnaud Ebalard, Thomas Petazzoni, Florian Fainelli, simon.guinot,
Eric Dumazet, netdev, edumazet, Cong Wang, linux-arm-kernel
In-Reply-To: <528E82C6.2010106@gmail.com>
On Thu, Nov 21, 2013 at 04:01:42PM -0600, Rob Herring wrote:
> The patch was to fix this issue[1]. It is fixed in the core code because
> dma_mask not being set has been a known issue with DT probing for some
> time. Since most drivers don't seem to care, we've gotten away with it.
> I thought the normal failure mode was drivers failing to probe.
It seems that very few drivers try to set their mask, so probably that
the default value was already OK even though less performant.
> As to why it helps performance, I'm not really sure. Perhaps it is
> causing some bounce buffers to be used.
That's also the thing I have been thinking about, and given this device
only has a 16-bit DDR bus, bounce buffers can make a difference.
> Rob
>
> [1] http://lists.xen.org/archives/html/xen-devel/2013-10/msg00092.html
Thanks for your quick explanation Rob!
Willy
^ permalink raw reply
* Re: [PATCH] net: sctp: find the correct highest_new_tsn in sack
From: Vlad Yasevich @ 2013-11-21 22:14 UTC (permalink / raw)
To: Chang Xiangzhong, nhorman, davem; +Cc: linux-sctp, netdev, linux-kernel
In-Reply-To: <1385070988-29554-1-git-send-email-changxiangzhong@gmail.com>
On 11/21/2013 04:56 PM, Chang Xiangzhong wrote:
> Function sctp_check_transmitted(transport t, ...) would iterate all of
> transport->transmitted queue and looking for the highest __newly__ acked tsn.
> The original algorithm would depend on the order of the assoc->transport_list
> (in function sctp_outq_sack line 1215 - 1226). The result might not be the
> expected due to the order of the tranport_list.
>
> Solution: checking if the exising is smaller than the new one before assigning
>
> Signed-off-by: Chang Xiangzhong <changxiangzhong@gmail.com>
Good find. This has been around for since day 1. It doesn't so much
depend on the order of the transport list, but on the order the
transports been used. I agree it is a problem if chunks have been
distributed across multiple transports and a singe SACK acking them all.
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> ---
> net/sctp/outqueue.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/sctp/outqueue.c b/net/sctp/outqueue.c
> index ef9e2bb..1b494fa 100644
> --- a/net/sctp/outqueue.c
> +++ b/net/sctp/outqueue.c
> @@ -1397,7 +1397,8 @@ static void sctp_check_transmitted(struct sctp_outq *q,
> */
> if (!tchunk->tsn_gap_acked) {
> tchunk->tsn_gap_acked = 1;
> - *highest_new_tsn_in_sack = tsn;
> + if (TSN_lt(*highest_new_tsn_in_sack, tsn))
> + *highest_new_tsn_in_sack = tsn;
> bytes_acked += sctp_data_size(tchunk);
> if (!tchunk->transport)
> migrate_bytes += sctp_data_size(tchunk);
>
^ permalink raw reply
* Re: [PATCH net-next 7/8] openvswitch: Drop user features if old user space attempted to create datapath
From: Thomas Graf @ 2013-11-21 22:20 UTC (permalink / raw)
To: Ben Hutchings
Cc: jesse, davem, dev, netdev, dborkman, ffusco, fleitner,
eric.dumazet
In-Reply-To: <1385058197.1586.15.camel@bwh-desktop.uk.level5networks.com>
On 11/21/13 at 06:23pm, Ben Hutchings wrote:
> On Thu, 2013-11-21 at 19:13 +0100, Thomas Graf wrote:
> > +
> > +/**
> > + * V2:
>
> This is not kernel-doc format so don't use '/**'.
I was hoping kernel-doc would pick it up but it doesn't.
I'll convert it.
> > + if (info->genlhdr->version < OVS_DP_VER_FEATURES) {
> > + WARN_ONCE(dp->user_features, "Dropping previously "
> > + "announced user features");
>
> Log messages shouldn't be split like this as it makes them harder to
> find. There should also be a newline at the end of the message.
Right, I'll fix this up. We seem to have many of these unfixed.
Jesse, do you want a full respin or just a v2 of this patch?
^ permalink raw reply
* Re: [PATCH v3] packet: fix use after free race in send path when dev is released
From: Ben Greear @ 2013-11-21 22:40 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, Salam Noureddine, Eric Dumazet
In-Reply-To: <1385049058-1946-1-git-send-email-dborkman@redhat.com>
On 11/21/2013 07:50 AM, Daniel Borkmann wrote:
> Salam reported a use after free bug in PF_PACKET that occurs when
> we're sending out frames on a socket bound device and suddenly the
> net device is being unregistered. It appears that commit 827d9780
> introduced a possible race condition between {t,}packet_snd() and
> packet_notifier(). In the case of a bound socket, packet_notifier()
> can drop the last reference to the net_device and {t,}packet_snd()
> might end up suddenly sending a packet over a freed net_device.
Thank you all for finding and fixing this!
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox