* Re: [PATCH v4 net-next] net: introduce dev_set_forwarding()
From: David Miller @ 2013-11-07 22:06 UTC (permalink / raw)
To: herbert; +Cc: bhutchings, eric.dumazet, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <20131107213111.GA6885@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 8 Nov 2013 05:31:11 +0800
> Sorry David, I just realised that this patch doesn't address
> this problem fully. While we can stop the generation of these
> packets in our own stack, if they're coming from the virt host
> or another guest, there is nothing we can do to stop them.
>
> So given virtio_net is now generating such packets, our choices
> are either to linearise them or deal with them properly in skb_segment.
Ok.
Aside from the segmentation issues, Eric's patch was a nice cleanup
which also made it such that we'd be able to get features back when
the blocking condition gets removed.
Given all of this, would you like me to revert his change for now?
^ permalink raw reply
* Re: [PATCH net-next] nfnetlink: do not ack malformed messages
From: Sergei Shtylyov @ 2013-11-07 23:03 UTC (permalink / raw)
To: Jiri Benc, netdev; +Cc: Pablo Neira Ayuso, Petr Matousek
In-Reply-To: <fa44451df8aa56773b1b17cbbd86ced8b54eca5a.1383850681.git.jbenc@redhat.com>
Hello.
On 11/07/2013 09:59 PM, Jiri Benc wrote:
> Commit 0628b123c96d ("netfilter: nfnetlink: add batch support and use it
> from nf_tables") introduced a bug leading to various crashes in netlink_ack
> when netlink message with invalid nlmsg_len was sent by an unprivileged
> user.
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
> ---
> net/netfilter/nfnetlink.c | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
> diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
> index 027f16a..046aa13 100644
> --- a/net/netfilter/nfnetlink.c
> +++ b/net/netfilter/nfnetlink.c
> @@ -363,13 +363,15 @@ static void nfnetlink_rcv(struct sk_buff *skb)
> struct net *net = sock_net(skb->sk);
> int msglen;
>
> - if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
> - return netlink_ack(skb, nlh, -EPERM);
> -
Hm, how it even compiled before your patch?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next] 8390 : Replace ei_debug with msg_enable/NETIF_MSG_* feature
From: Matthew Whitehead @ 2013-11-07 21:55 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev
In-Reply-To: <1383860994.9263.31.camel@joe-AO722>
> I think that's OK if/when there are multiple statements
> in a block after the netif_msg_<type> like:
>
> if (netif_msg_rx_err(ei_local)) {
> foo();
> bar();
> }
>
> > I did a V2 in this style, but I'll change it to
> >
> > netif_<level>(struct ei_device *, type, struct net_device *, fmt, ...)
> >
> > if that is the more preferred style
>
> Otherwise I think netif_<level> is the "more preferred" style.
>
>
Joe,
I'll do another version using netif_<level> and post it as V2.
- Matthew
^ permalink raw reply
* Re: [PATCH v4 net-next] net: introduce dev_set_forwarding()
From: Eric Dumazet @ 2013-11-07 21:54 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, bhutchings, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <20131107213111.GA6885@gondor.apana.org.au>
On Fri, 2013-11-08 at 05:31 +0800, Herbert Xu wrote:
> Sorry David, I just realised that this patch doesn't address
> this problem fully. While we can stop the generation of these
> packets in our own stack, if they're coming from the virt host
> or another guest, there is nothing we can do to stop them.
>
> So given virtio_net is now generating such packets, our choices
> are either to linearise them or deal with them properly in skb_segment.
Hi Herbert
I believe I did this on my patch.
Note that there is absolutely no requirement on how are the skb found in
frag_list (their length is not a multiple of MSS)
For the ease of discussion, once patched skb_segment() looks like :
/**
* skb_segment - Perform protocol segmentation on skb.
* @skb: buffer to segment
* @features: features for the output path (see dev->features)
*
* This function performs segmentation on the given skb. It returns
* a pointer to the first in a list of new skbs for the segments.
* In case of error it returns ERR_PTR(err).
*/
struct sk_buff *skb_segment(struct sk_buff *head_skb, netdev_features_t features)
{
struct sk_buff *segs = NULL;
struct sk_buff *tail = NULL;
struct sk_buff *cskb = head_skb;
unsigned int mss = skb_shinfo(head_skb)->gso_size;
unsigned int doffset = head_skb->data - skb_mac_header(head_skb);
unsigned int tot_len; /* should reach head_skb->len at the end */
unsigned int offset = doffset; /* offset in cskb->data */
unsigned int tnl_hlen = skb_tnl_header_len(head_skb);
unsigned int headroom;
unsigned int len;
__be16 proto;
bool csum;
int sg = !!(features & NETIF_F_SG);
int cur_frag = 0, nfrags = skb_shinfo(cskb)->nr_frags;
unsigned int data_len, cur_frag_offset = 0;
int err = -ENOMEM;
proto = skb_network_protocol(head_skb);
if (unlikely(!proto))
return ERR_PTR(-EINVAL);
csum = !!can_checksum_protocol(features, proto);
__skb_push(head_skb, doffset);
headroom = skb_headroom(head_skb);
for (tot_len = doffset; tot_len < head_skb->len; tot_len += len) {
struct sk_buff *nskb;
skb_frag_t *frag;
int hsize, size, remain;
len = head_skb->len - tot_len;
if (len > mss)
len = mss;
hsize = skb_headlen(cskb) - offset;
if (hsize < 0)
hsize = 0;
if (hsize > len || !sg)
hsize = len;
nskb = __alloc_skb(hsize + doffset + headroom,
GFP_ATOMIC, skb_alloc_rx_flag(head_skb),
NUMA_NO_NODE);
if (unlikely(!nskb))
goto err;
skb_reserve(nskb, headroom);
__skb_put(nskb, doffset);
if (segs)
tail->next = nskb;
else
segs = nskb;
tail = nskb;
__copy_skb_header(nskb, head_skb);
nskb->mac_len = head_skb->mac_len;
skb_headers_offset_update(nskb, skb_headroom(nskb) - headroom);
skb_copy_from_linear_data_offset(head_skb, -tnl_hlen,
nskb->data - tnl_hlen,
doffset + tnl_hlen);
if (!sg) {
nskb->ip_summed = CHECKSUM_NONE;
nskb->csum = skb_copy_and_csum_bits(head_skb, tot_len,
skb_put(nskb, len),
len, 0);
offset += len;
continue;
}
frag = skb_shinfo(nskb)->frags;
skb_copy_from_linear_data_offset(cskb, offset,
skb_put(nskb, hsize), hsize);
offset += hsize;
nskb->data_len = len - hsize;
nskb->len += nskb->data_len;
nskb->truesize += nskb->data_len;
skb_shinfo(nskb)->tx_flags = skb_shinfo(head_skb)->tx_flags & SKBTX_SHARED_FRAG;
for (data_len = 0; data_len < nskb->data_len; data_len += remain) {
remain = nskb->data_len - data_len;
if (unlikely(cur_frag >= nfrags)) {
if (cskb == head_skb)
cskb = skb_shinfo(head_skb)->frag_list;
else
cskb = cskb->next;
if (!cskb) {
WARN_ON_ONCE(1);
goto err;
}
cur_frag = 0;
cur_frag_offset = 0;
nfrags = skb_shinfo(cskb)->nr_frags;
offset = 0;
if (skb_headlen(cskb)) {
char *data;
struct page *page;
remain = min_t(int, remain, skb_headlen(cskb));
pr_err_once("remain %d\n", remain);
if (likely(cskb->head_frag)) {
data = cskb->data;
page = virt_to_head_page(data);
get_page(page);
} else {
data = __netdev_alloc_frag(SKB_DATA_ALIGN(remain),
GFP_ATOMIC);
/* Really this should not happen, fix the caller ! */
WARN_ON_ONCE(1);
if (!data)
goto err;
memcpy(data, cskb->data, remain);
page = virt_to_head_page(data);
}
frag->page.p = page;
frag->page_offset = data - (char *)page_address(page);
skb_frag_size_set(frag, remain);
frag++;
offset = remain;
continue;
}
}
*frag = skb_shinfo(cskb)->frags[cur_frag];
__skb_frag_ref(frag);
frag->page_offset += cur_frag_offset;
skb_frag_size_sub(frag, cur_frag_offset);
size = skb_frag_size(frag);
if (size <= remain) {
cur_frag++;
cur_frag_offset = 0;
remain = size;
} else {
skb_frag_size_set(frag, remain);
cur_frag_offset += remain;
}
frag++;
}
skb_shinfo(nskb)->nr_frags = frag - skb_shinfo(nskb)->frags;
if (!csum) {
nskb->csum = skb_checksum(nskb, doffset,
nskb->len - doffset, 0);
nskb->ip_summed = CHECKSUM_NONE;
}
}
return segs;
err:
while ((cskb = segs)) {
segs = cskb->next;
kfree_skb(cskb);
}
return ERR_PTR(err);
}
EXPORT_SYMBOL_GPL(skb_segment);
^ permalink raw reply
* Re: [PATCH net-next] 8390 : Replace ei_debug with msg_enable/NETIF_MSG_* feature
From: Joe Perches @ 2013-11-07 21:49 UTC (permalink / raw)
To: Matthew Whitehead; +Cc: netdev
In-Reply-To: <20131107214222.GA28471@mwhitehe.csb>
On Thu, 2013-11-07 at 16:42 -0500, Matthew Whitehead wrote:
> On Wed, Nov 06, 2013 at 03:49:13PM -0800, Joe Perches wrote:
> > On Wed, 2013-11-06 at 15:56 -0500, Matthew Whitehead wrote:
> > > Removed the shared ei_debug variable. Replaced it by adding u32 msg_enable to
> > > the private struct ei_device. Now each 8390 ethernet instance has a per-device
> > > logging variable.
> > >
> > > Changed printk() calls to netdev_(dbg|info|warn|err) when possible.
> >
> > Hello Matthew.
> >
> > Ideally, some of these would use:
> >
> > netif_<level>(struct ei_device *, type, struct net_device *, fmt, ...)
> >
> > > @@ -352,10 +360,12 @@ static void
> > []
> > > + if (ei_local->msg_enable & NETIF_MSG_HW)
> > > + netdev_dbg(dev, "resetting the 8390 t=%ld...\n", jiffies);
> >
> > netif_dbg(ei_local, hw, dev, "resetting the 8390 t=%...\n", jiffies);
> >
>
> Joe,
Hi Matthew
> what about using netif_msg_(drv|probe|ifdown|rx_err|tx_err|tx_queued|intr|rx_status|hw) calls?
> For example:
>
> if (netif_msg_rx_err(ei_local))
> netdev_err(dev, "Couldn't allocate a sk_buff of size %d\n", pkt_len);
I think that's OK if/when there are multiple statements
in a block after the netif_msg_<type> like:
if (netif_msg_rx_err(ei_local)) {
foo();
bar();
}
> I did a V2 in this style, but I'll change it to
>
> netif_<level>(struct ei_device *, type, struct net_device *, fmt, ...)
>
> if that is the more preferred style
Otherwise I think netif_<level> is the "more preferred" style.
^ permalink raw reply
* Re: [PATCH net-next] 8390 : Replace ei_debug with msg_enable/NETIF_MSG_* feature
From: Matthew Whitehead @ 2013-11-07 21:42 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev
In-Reply-To: <1383781753.7940.38.camel@joe-AO722>
On Wed, Nov 06, 2013 at 03:49:13PM -0800, Joe Perches wrote:
> On Wed, 2013-11-06 at 15:56 -0500, Matthew Whitehead wrote:
> > Removed the shared ei_debug variable. Replaced it by adding u32 msg_enable to
> > the private struct ei_device. Now each 8390 ethernet instance has a per-device
> > logging variable.
> >
> > Changed printk() calls to netdev_(dbg|info|warn|err) when possible.
>
> Hello Matthew.
>
> Ideally, some of these would use:
>
> netif_<level>(struct ei_device *, type, struct net_device *, fmt, ...)
>
> > @@ -352,10 +360,12 @@ static void
> []
> > + if (ei_local->msg_enable & NETIF_MSG_HW)
> > + netdev_dbg(dev, "resetting the 8390 t=%ld...\n", jiffies);
>
> netif_dbg(ei_local, hw, dev, "resetting the 8390 t=%...\n", jiffies);
>
Joe,
what about using netif_msg_(drv|probe|ifdown|rx_err|tx_err|tx_queued|intr|rx_status|hw) calls?
For example:
if (netif_msg_rx_err(ei_local))
netdev_err(dev, "Couldn't allocate a sk_buff of size %d\n", pkt_len);
I did a V2 in this style, but I'll change it to
netif_<level>(struct ei_device *, type, struct net_device *, fmt, ...)
if that is the more preferred style
- Matthew
^ permalink raw reply
* Re: [PATCH v4 net-next] net: introduce dev_set_forwarding()
From: Herbert Xu @ 2013-11-07 21:31 UTC (permalink / raw)
To: David Miller
Cc: bhutchings, eric.dumazet, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <20131107.161755.355597965034457889.davem@davemloft.net>
On Thu, Nov 07, 2013 at 04:17:55PM -0500, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Mon, 4 Nov 2013 16:55:30 +0000
>
> > On Sat, 2013-11-02 at 12:58 -0700, Eric Dumazet wrote:
> >> From: Eric Dumazet <edumazet@google.com>
> >>
> >> Christoph Paasch and Jerry Chu reported crashes in skb_segment() caused
> >> by commit 8a29111c7ca6 ("net: gro: allow to build full sized skb")
> >>
> >> skb_segment() only deals with a frag_list chain containing MSS sized
> >> fragments. Even if we fix this problem, its better if GRO layer
> >> doesn't build skb with a frag_list in the first place, to let TSO
> >> packets reaching output devices.
> >>
> >> David Miller and Ben Hutchings suggested we keep track of number of
> >> forwarding users to be able to :
> >>
> >> - Disable LRO
> >> - Make sure GRO layer do not use skb frag_list to extend skb capacity
> >>
> >> Note that after this patch, LRO is automatically re-enabled if
> >> forwarding is disabled on the device, or if a device is removed
> >> from a bridge.
> > [...]
> >
> > Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
>
> Applied, thanks everyone.
Sorry David, I just realised that this patch doesn't address
this problem fully. While we can stop the generation of these
packets in our own stack, if they're coming from the virt host
or another guest, there is nothing we can do to stop them.
So given virtio_net is now generating such packets, our choices
are either to linearise them or deal with them properly in skb_segment.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 2/2] x86: add prefetching to do_csum
From: Neil Horman @ 2013-11-07 21:23 UTC (permalink / raw)
To: Andi Kleen
Cc: linux-kernel, sebastien.dugue, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, netdev
In-Reply-To: <87iow58eqf.fsf@tassilo.jf.intel.com>
On Wed, Nov 06, 2013 at 12:19:52PM -0800, Andi Kleen wrote:
> Neil Horman <nhorman@tuxdriver.com> writes:
>
> > do_csum was identified via perf recently as a hot spot when doing
> > receive on ip over infiniband workloads. After alot of testing and
> > ideas, we found the best optimization available to us currently is to
> > prefetch the entire data buffer prior to doing the checksum
>
> On what CPU? Most modern CPUs should not have any trouble at all
> prefetching a linear access.
>
> Also for large buffers it is unlikely that all the prefetches
> are actually executed, there is usually some limit.
>
> As a minimum you would need:
> - run it with a range of buffer sizes
> - run this on a range of different CPUs and show no major regressions
> - describe all of this actually in the description
>
> But I find at least this patch very dubious.
>
> -Andi
>
Well, if you look back in the thread, you can see several tests done with
various forms of prefetching, that show performance improvements, but if you
want them all collected, heres what I have, using the perf bench from patch 1.
As you can see, you're right, on newer hardware theres negligible advantage (but
no regression that I can see). On older hardware however, we see a definate
improvement (up to 3%). I'm afraid I don't have a wide variety of hardware
handy at the moment to do any large scale testing on multiple cpu's. But if you
have them available, please share your results
Regards
Neil
vendor_id : AuthenticAMD
cpu family : 16
model : 8
model name : AMD Opteron(tm) Processor 4130
stepping : 0
microcode : 0x10000da
cpu MHz : 800.000
cache size : 512 KB
physical id : 1
siblings : 4
core id : 3
cpu cores : 4
apicid : 11
initial apicid : 11
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp
lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor
cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate npt lbrv svm_lock
nrip_save pausefilter
bogomips : 5200.49
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
Without prefecth:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 1.432338
1500B | 128MB | 1000000 | 1.426212
1500B | 256MB | 1000000 | 1.425988
1500B | 512MB | 1000000 | 1.517873
9000B | 64MB | 1000000 | 0.897998
9000B | 128MB | 1000000 | 0.884120
9000B | 256MB | 1000000 | 0.881770
9000B | 512MB | 1000000 | 0.883644
64KB | 64MB | 1000000 | 0.813054
64KB | 128MB | 1000000 | 0.801859
64KB | 256MB | 1000000 | 0.796415
64KB | 512MB | 1000000 | 0.793869
With prefetch:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 1.442855
1500B | 128MB | 1000000 | 1.438841
1500B | 256MB | 1000000 | 1.427324
1500B | 512MB | 1000000 | 1.462715
9000B | 64MB | 1000000 | 0.894097
9000B | 128MB | 1000000 | 0.884738
9000B | 256MB | 1000000 | 0.881370
9000B | 512MB | 1000000 | 0.884799
64KB | 64MB | 1000000 | 0.813512
64KB | 128MB | 1000000 | 0.801596
64KB | 256MB | 1000000 | 0.795575
64KB | 512MB | 1000000 | 0.793927
==========================================================================================
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
stepping : 7
microcode : 0x29
cpu MHz : 2754.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3
cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx
lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept
vpid
bogomips : 6784.46
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
Without prefetch:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 1.343645
1500B | 128MB | 1000000 | 1.345782
1500B | 256MB | 1000000 | 1.353145
1500B | 512MB | 1000000 | 1.354844
9000B | 64MB | 1000000 | 0.856552
9000B | 128MB | 1000000 | 0.852786
9000B | 256MB | 1000000 | 0.854705
9000B | 512MB | 1000000 | 0.863308
64KB | 64MB | 1000000 | 0.771888
64KB | 128MB | 1000000 | 0.773453
64KB | 256MB | 1000000 | 0.771728
64KB | 512MB | 1000000 | 0.771390
With prefetching:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 1.344733
1500B | 128MB | 1000000 | 1.342285
1500B | 256MB | 1000000 | 1.344818
1500B | 512MB | 1000000 | 1.342632
9000B | 64MB | 1000000 | 0.851043
9000B | 128MB | 1000000 | 0.850629
9000B | 256MB | 1000000 | 0.852207
9000B | 512MB | 1000000 | 0.851927
64KB | 64MB | 1000000 | 0.768549
64KB | 128MB | 1000000 | 0.768623
64KB | 256MB | 1000000 | 0.768938
64KB | 512MB | 1000000 | 0.768824
==========================================================================================
vendor_id : AuthenticAMD
cpu family : 16
model : 9
model name : AMD Opteron(tm) Processor 6172
stepping : 1
microcode : 0x10000d9
cpu MHz : 800.000
cache size : 512 KB
physical id : 1
siblings : 12
core id : 5
cpu cores : 12
apicid : 43
initial apicid : 27
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp
lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid amd_dcm pni
monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a
misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate npt lbrv
svm_lock nrip_save pausefilter
bogomips : 4189.63
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate
Without prefetch:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 1.415370
1500B | 128MB | 1000000 | 1.437025
1500B | 256MB | 1000000 | 1.424822
1500B | 512MB | 1000000 | 1.442021
9000B | 64MB | 1000000 | 0.891699
9000B | 128MB | 1000000 | 0.884261
9000B | 256MB | 1000000 | 0.880179
9000B | 512MB | 1000000 | 0.882190
64KB | 64MB | 1000000 | 0.813047
64KB | 128MB | 1000000 | 0.800755
64KB | 256MB | 1000000 | 0.795207
64KB | 512MB | 1000000 | 0.792065
With prefetch:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 1.424003
1500B | 128MB | 1000000 | 1.435567
1500B | 256MB | 1000000 | 1.446858
1500B | 512MB | 1000000 | 1.459407
9000B | 64MB | 1000000 | 0.899858
9000B | 128MB | 1000000 | 0.885170
9000B | 256MB | 1000000 | 0.883936
9000B | 512MB | 1000000 | 0.886158
64KB | 64MB | 1000000 | 0.814136
64KB | 128MB | 1000000 | 0.802202
64KB | 256MB | 1000000 | 0.796140
64KB | 512MB | 1000000 | 0.793792
==========================================================================================
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(tm) XP 2800+
stepping : 0
cpu MHz : 2079.461
cache size : 512 KB
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips : 4158.92
clflush size : 32
cache_alignment : 32
address sizes : 34 bits physical, 32 bits virtual
power management: ts
Without prefetch:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 3.335217
1500B | 128MB | 1000000 | 3.403103
1500B | 256MB | 1000000 | 3.445059
1500B | 512MB | 1000000 | 3.742008
9000B | 64MB | 1000000 | 47.466255
9000B | 128MB | 1000000 | 47.742751
9000B | 256MB | 1000000 | 47.965001
9000B | 512MB | 1000000 | 48.589349
64KB | 64MB | 1000000 | 118.088638
64KB | 128MB | 1000000 | 118.261744
64KB | 256MB | 1000000 | 118.349641
64KB | 512MB | 1000000 | 118.695321
With prefetch:
length | Set Sz| iterations | cycles/byte
1500B | 64MB | 1000000 | 3.231086
1500B | 128MB | 1000000 | 3.423485
1500B | 256MB | 1000000 | 3.278899
1500B | 512MB | 1000000 | 3.545504
9000B | 64MB | 1000000 | 46.907795
9000B | 128MB | 1000000 | 47.321743
9000B | 256MB | 1000000 | 47.306189
9000B | 512MB | 1000000 | 48.144320
64KB | 64MB | 1000000 | 117.897735
64KB | 128MB | 1000000 | 118.122266
64KB | 256MB | 1000000 | 118.126397
64KB | 512MB | 1000000 | 118.546901
^ permalink raw reply
* Re: [PATCH v4 net-next] net: introduce dev_set_forwarding()
From: David Miller @ 2013-11-07 21:17 UTC (permalink / raw)
To: bhutchings
Cc: eric.dumazet, christoph.paasch, herbert, netdev, hkchu, mwdalton
In-Reply-To: <1383584130.1553.2.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 4 Nov 2013 16:55:30 +0000
> On Sat, 2013-11-02 at 12:58 -0700, Eric Dumazet wrote:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> Christoph Paasch and Jerry Chu reported crashes in skb_segment() caused
>> by commit 8a29111c7ca6 ("net: gro: allow to build full sized skb")
>>
>> skb_segment() only deals with a frag_list chain containing MSS sized
>> fragments. Even if we fix this problem, its better if GRO layer
>> doesn't build skb with a frag_list in the first place, to let TSO
>> packets reaching output devices.
>>
>> David Miller and Ben Hutchings suggested we keep track of number of
>> forwarding users to be able to :
>>
>> - Disable LRO
>> - Make sure GRO layer do not use skb frag_list to extend skb capacity
>>
>> Note that after this patch, LRO is automatically re-enabled if
>> forwarding is disabled on the device, or if a device is removed
>> from a bridge.
> [...]
>
> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH v2] phy: Add MOXA MDIO driver
From: David Miller @ 2013-11-07 20:37 UTC (permalink / raw)
To: jonas.jensen
Cc: netdev, linux-arm-kernel, linux-kernel, devicetree, f.fainelli,
grant.likely
In-Reply-To: <1383666901-22354-1-git-send-email-jonas.jensen@gmail.com>
From: Jonas Jensen <jonas.jensen@gmail.com>
Date: Tue, 5 Nov 2013 16:55:01 +0100
> The MOXA UC-711X hardware(s) has an ethernet controller that seem
> to be developed internally. The IC used is "RTL8201CP".
>
> This patch adds an MDIO driver which handles the MII bus.
>
> Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
Applied, thanks Jonas.
^ permalink raw reply
* no new features at this time
From: David Miller @ 2013-11-07 20:32 UTC (permalink / raw)
To: netdev
We are in the merge window and Linus is going to start taking pull
requests in next week.
This means there should be no new feature additions being submitted
right now.
John has a wireless pull request pending for me, but that is the only
new thing I want to see showing up in patchwork at this time.
I am going to reject and delete from patchwork any patches which
are not appropriate until after the merge window closes and
net-next reopens.
Thanks in advance for your cooperation.
^ permalink raw reply
* Re: [BUG] v3.12-rc5-139-gbdeeab6 assertion failed at drivers/net/bonding/bond_main.c (3398)
From: Veaceslav Falico @ 2013-11-07 20:18 UTC (permalink / raw)
To: David Miller; +Cc: thomas, netdev, fubar, andy, nikolay, robbat2
In-Reply-To: <20131107.151212.489598950578675166.davem@davemloft.net>
On Thu, Nov 07, 2013 at 03:12:12PM -0500, David Miller wrote:
>From: Veaceslav Falico <vfalico@redhat.com>
>Date: Thu, 7 Nov 2013 15:24:18 +0100
>
>> Sorry for bringing this up - completely my fault. There are further
>> reports
>> of this bug in mainline. I've read the
>> ./Documentation/networking/netdev-FAQ.txt but haven't seen a way to
>> get a
>> fix that got in net-next to the (correct) net tree.
>>
>> Is there any way to do it?
>>
>> Sorry again for the mess :-(.
>
>Since we're in the merge window the tree going to Linus next would
>be net-next, and the fix is there.
>
>Once it hits Linus's tree I can queue it up for -stable.
Awesome, please do, thank you.
And sorry again for the noise.
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 0/2] bonding: extend round-robin mode
From: David Miller @ 2013-11-07 20:12 UTC (permalink / raw)
To: nikolay; +Cc: netdev, andy, fubar, vfalico
In-Reply-To: <1383655902-18744-1-git-send-email-nikolay@redhat.com>
From: Nikolay Aleksandrov <nikolay@redhat.com>
Date: Tue, 5 Nov 2013 13:51:40 +0100
> This small patchset adds a new option called packets_per_slave to the
> bonding which aims to extend round-robin mode with the following effects:
> 0 - choose the slave id at random
> 1 - packet per slave (standard round-robin, default option value)
> >1 - transmit >1 packets per slave, switch the slaves in round-robin
> Patch02 adds a description for the new option to the bonding documentation.
Series applied, thanks.
^ permalink raw reply
* Re: [BUG] v3.12-rc5-139-gbdeeab6 assertion failed at drivers/net/bonding/bond_main.c (3398)
From: David Miller @ 2013-11-07 20:12 UTC (permalink / raw)
To: vfalico; +Cc: thomas, netdev, fubar, andy, nikolay, robbat2
In-Reply-To: <20131107142418.GL19702@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Thu, 7 Nov 2013 15:24:18 +0100
> Sorry for bringing this up - completely my fault. There are further
> reports
> of this bug in mainline. I've read the
> ./Documentation/networking/netdev-FAQ.txt but haven't seen a way to
> get a
> fix that got in net-next to the (correct) net tree.
>
> Is there any way to do it?
>
> Sorry again for the mess :-(.
Since we're in the merge window the tree going to Linus next would
be net-next, and the fix is there.
Once it hits Linus's tree I can queue it up for -stable.
^ permalink raw reply
* [PATCH ethtool] sfc: Remove preprocessor condition from register table definitions
From: Ben Hutchings @ 2013-11-07 19:58 UTC (permalink / raw)
To: netdev
This condition was mistakenly copied from the corresponding
definitions in the out-of-tree version of sfc. It has no effect here.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
I've applied this change just after the 3.12 tag.
Ben.
sfc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/sfc.c b/sfc.c
index 1bb3689..9478b38 100644
--- a/sfc.c
+++ b/sfc.c
@@ -3739,9 +3739,7 @@ static const struct efx_nic_reg_table efx_nic_reg_tables[] = {
REGISTER_TABLE_CZ(MC_TREG_SMEM),
/* MSIX_PBA_TABLE is not mapped */
/* SRM_DBG is not mapped (and is redundant with BUF_FLL_TBL) */
-#if !defined(EFX_USE_KCOMPAT) || defined(EFX_HAVE_VMALLOC_REG_DUMP_BUF)
REGISTER_TABLE_BZ(RX_FILTER_TBL0),
-#endif
REGISTER_TABLE_DZ(BIU_MC_SFT_STATUS),
};
--
1.8.1.4
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply related
* ethtool 3.12 released
From: Ben Hutchings @ 2013-11-07 19:56 UTC (permalink / raw)
To: netdev
ethtool version 3.12 has been released.
Home page: https://ftp.kernel.org/pub/software/network/ethtool/
Download link:
https://ftp.kernel.org/pub/software/network/ethtool/ethtool-3.12.tar.xz
Release notes:
* Fix: Remove alternate method to check for VLAN tag offload on Linux
< 2.6.37 (-k/-K options)
* Fix: Hide state of VLAN tag offload and LRO if the kernel is too old
for us to reliably detect them (-k option)
* Feature: Add register dump support for Solarflare SFC9100 family
(-d option)
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] wcn36xx: Fix logging macro with unnecessary semicolon
From: Joe Perches @ 2013-11-07 19:40 UTC (permalink / raw)
To: Eugene Krasnikov
Cc: Luis R. Rodriguez, John W. Linville, wcn36xx, linux-wireless,
netdev, linux-kernel@vger.kernel.org, ath5k-devel, ath9k-devel,
ath10k, Kalle Valo, wil6210
In-Reply-To: <CAFSJ42Y-3BZqj+JRNa8wdxjnm1fguD8ToH5Oj0m56yT5NexdVQ@mail.gmail.com>
On Thu, 2013-11-07 at 07:32 +0000, Eugene Krasnikov wrote:
> Hi Joe,
Hi Eugene.
> I personally like the idea of making some kind of framework on top of
> printing because all ath drivers are using the same printing approach
> and combining all that code in one place will reduce amount of code in
> each particular driver. As a true engineer i like when it's less code
> = less work to do = less bugs:)
>
> Suggestion is to send a patch with semicolon fix only
It's a one line fix, and pretty trivial to do yourself if you
want it.
I do think though the slightly odd wcn36xx_<level> uses of:
-#define wcn36xx_err(fmt, arg...) \
- printk(KERN_ERR pr_fmt("ERROR " fmt), ##arg);
-
-#define wcn36xx_warn(fmt, arg...) \
- printk(KERN_WARNING pr_fmt("WARNING " fmt), ##arg)
-
-#define wcn36xx_info(fmt, arg...) \
- printk(KERN_INFO pr_fmt(fmt), ##arg)
-
[]
+#define wcn36xx_err(fmt, ...) \
+ pr_err("ERROR " fmt, ##__VA_ARGS__)
+#define wcn36xx_warn(fmt, ...) \
+ pr_warn("WARNING " fmt, ##__VA_ARGS__)
+#define wcn36xx_info(fmt, ...) \
+ pr_info(fmt, ##__VA_ARGS__)
should still be converted to more normal pr_<level> like I did.
I don't believe that prefixing of "ERROR " and "WARNING " to
pr_err and pr_warn actually gain anything as the same level
information can be got already with dmesg -r via the "<3>" and
"<4>" prefixes or dmesg -l3 -l4
> have a
> second round of convincing ath guys to change printing code. How does
> that sound?
Luis? Kalle? Other Qualcomm/Atheros folk?
One of the nominal benefits of separating the ath_<level>
macros by subsystem was perf/tracing. I believe some of the
ath subsystems have integrated the dmesg and tracing code.
I'm not sure how separable those may be here or if it's even
desirable to separate them. I'd guess not.
^ permalink raw reply
* [PATCH net-next] nfnetlink: do not ack malformed messages
From: Jiri Benc @ 2013-11-07 18:59 UTC (permalink / raw)
To: netdev; +Cc: Pablo Neira Ayuso, Petr Matousek
Commit 0628b123c96d ("netfilter: nfnetlink: add batch support and use it
from nf_tables") introduced a bug leading to various crashes in netlink_ack
when netlink message with invalid nlmsg_len was sent by an unprivileged
user.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
net/netfilter/nfnetlink.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/nfnetlink.c b/net/netfilter/nfnetlink.c
index 027f16a..046aa13 100644
--- a/net/netfilter/nfnetlink.c
+++ b/net/netfilter/nfnetlink.c
@@ -363,13 +363,15 @@ static void nfnetlink_rcv(struct sk_buff *skb)
struct net *net = sock_net(skb->sk);
int msglen;
- if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
- return netlink_ack(skb, nlh, -EPERM);
-
if (nlh->nlmsg_len < NLMSG_HDRLEN ||
skb->len < nlh->nlmsg_len)
return;
+ if (!ns_capable(net->user_ns, CAP_NET_ADMIN)) {
+ netlink_ack(skb, nlh, -EPERM);
+ return;
+ }
+
if (nlh->nlmsg_type == NFNL_MSG_BATCH_BEGIN) {
struct nfgenmsg *nfgenmsg;
--
1.7.6.5
^ permalink raw reply related
* [PATCH net] netlink: fix netlink_ack with large messages
From: Jiri Benc @ 2013-11-07 18:57 UTC (permalink / raw)
To: netdev; +Cc: Pablo Neira Ayuso
Commit c05cdb1b864f ("netlink: allow large data transfers from user-space")
does not handle cases where netlink_ack is used to report an error. In such
case, the original message is copied to the ack message, which needs to be
large enough.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
---
net/netlink/af_netlink.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 8df7f64..090f624 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1809,7 +1809,7 @@ out_put:
sock_put(sk);
out:
#endif
- return alloc_skb(size, gfp_mask);
+ return netlink_alloc_large_skb(size, gfp_mask);
}
EXPORT_SYMBOL_GPL(netlink_alloc_skb);
--
1.7.6.5
^ permalink raw reply related
* Re: ipv6: a question about ECMP
From: sowmini varadhan @ 2013-11-07 18:32 UTC (permalink / raw)
To: Duan Jiong, David Miller, nicolas.dichtel, netdev
In-Reply-To: <20131107121602.GI8144@order.stressinduktion.org>
On Thu, Nov 7, 2013 at 7:16 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> Hi Duan!
>
> On Thu, Nov 07, 2013 at 06:33:20PM +0800, Duan Jiong wrote:
>> After reading the ip6_pol_route(), i have a question about ECMP. Why we call
>> the rt6_multipath_select() after calling rt6_select()?
>> In my opinion, the route returned by rt6_select() has a highest score, but the route
>> returned by rt6_multipath_select() may has a lower score than the former, because the
>> ECMP don't take the route preference into consideration. That means that the kernel will
>> choose a less-desirable route.
>
> ECMP routes only differ in the gateway the specify, so I doubt there will be
> any change in the score they woud receive. rt6_multipath_select does merly
> make sure we don't select the same route again and again.
rt6_multipath_select() -> rt6_socre_route() seems to require that the
interface *must* matchi, which is consistent with your assertion above that
"ECMP routes differ in gw only".
But for IPv6, the gw addr is a a link-local, which is only required to be
unique on the link. Thus, e.g., you can have fe80::1 as the gw on both eth0 and
eth1.
What is the assumption around "cost" for ECMP here- are we assuming some
form of link bundling (Section 6 of rfc 2991) here? or is the "multiple parallel
links" case handled somewhere else, that I am missing?
--Sowmini
>
> Please note, the rt6_info's siblings fields were added for the solely purpose
> of ECMP and the insertion only updates the siblings list if the above criteria
> did hold. They make sure the routes lookup up do differ on each lookup, so it
> does actually do multipath and does not depend on the order the routes where
> inserted.
>
> Hope that helps,
>
> Hannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [3/3] gso: Handle malicious GRO packets without crashing
From: Ben Hutchings @ 2013-11-07 18:18 UTC (permalink / raw)
To: Herbert Xu
Cc: Eric Dumazet, David Miller, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <20131107070847.GC31638@gondor.apana.org.au>
On Thu, 2013-11-07 at 15:08 +0800, Herbert Xu wrote:
> As virtio_net can now generate GRO frag_list packets without
> sufficient verification, we need to handle malicious GRO packets
> thrown at us.
>
> This patch converts to affected BUG_ONs in skb_segment to rate-
> limited warnings.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index bcc3f1c..fb1106d 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -2881,7 +2881,15 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> while (tail->next)
> tail = tail->next;
>
> - BUG_ON(fskb && tail->len != len + doffset);
Oh well, disregard my previous request for a comment.
> + if (fskb && tail->len != len + doffset) {
> + net_warn_ratelimited(
> + "skb_segment: "
> + "illegal GSO fragment: %u %u\n",
> + tail->len, len + doffset);
> + kfree(nskb);
kfree_skb()
> + err = -EINVAL;
> + goto err;
> + }
>
> len = nskb->len;
> kfree(nskb);
> @@ -2929,7 +2937,15 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> if (pos < offset + len) {
> struct sk_buff *fskb2 = fskb;
>
> - BUG_ON(pos + fskb->len != offset + len);
> + if (pos + fskb->len != offset + len) {
> + net_warn_ratelimited(
> + "skb_segment: "
> + "illegal GSO trailer: %u %u\n",
> + pos + fskb->len, offset + len);
> + kfree(nskb);
kfree_skb()
> + err = -EINVAL;
> + goto err;
> + }
>
> pos += fskb->len;
> fskb = fskb->next;
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [2/3] gso: Handle new frag_list of frags GRO packets
From: Ben Hutchings @ 2013-11-07 18:16 UTC (permalink / raw)
To: Herbert Xu
Cc: Eric Dumazet, David Miller, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <20131107070647.GB31638@gondor.apana.org.au>
On Thu, 2013-11-07 at 15:06 +0800, Herbert Xu wrote:
> 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 by calling skb_segment for each
> frag_list entry. The depth of recursion is limited to just one.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 88b7dc6..bcc3f1c 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
[...]
> @@ -2855,8 +2853,40 @@ 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)
> - goto perform_csum_check;
> + if (fskb != skb_shinfo(skb)->frag_list) {
> + struct sk_buff *nsegs;
> +
> + if (nskb->len == len + doffset)
> + goto perform_csum_check;
> +
> + SKB_FRAG_ASSERT(nskb);
> +
> + __skb_pull(nskb, doffset);
> + skb_shinfo(nskb)->gso_size = mss;
> + nsegs = skb_segment(nskb, features);
> +
> + err = PTR_ERR(nsegs);
> + if (IS_ERR(nsegs)) {
> + kfree(nskb);
Should be kfree_skb().
> + goto err;
> + }
> + err = -ENOMEM;
It would be clearer to put this in front of the 'err' label:
err_nomem:
err = -ENOMEM;
and change the allocation failure paths to goto err_nomem.
> + if (segs)
> + tail->next = nsegs;
> + else
> + segs = nsegs;
> +
> + tail = nsegs;
> + while (tail->next)
> + tail = tail->next;
> +
> + BUG_ON(fskb && tail->len != len + doffset);
Deserves a comment, maybe?
> + len = nskb->len;
> + kfree(nskb);
> + continue;
> + }
>
> if (!sg) {
> nskb->ip_summed = CHECKSUM_NONE;
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [3/3] gso: Handle malicious GRO packets without crashing
From: Sergei Shtylyov @ 2013-11-07 19:13 UTC (permalink / raw)
To: Herbert Xu, Eric Dumazet
Cc: Ben Hutchings, David Miller, christoph.paasch, netdev, hkchu,
mwdalton
In-Reply-To: <20131107070847.GC31638@gondor.apana.org.au>
Hello.
On 11/07/2013 10:08 AM, Herbert Xu wrote:
> As virtio_net can now generate GRO frag_list packets without
> sufficient verification, we need to handle malicious GRO packets
> thrown at us.
> This patch converts to affected BUG_ONs in skb_segment to rate-
> limited warnings.
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index bcc3f1c..fb1106d 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -2881,7 +2881,15 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> while (tail->next)
> tail = tail->next;
>
> - BUG_ON(fskb && tail->len != len + doffset);
> + if (fskb && tail->len != len + doffset) {
> + net_warn_ratelimited(
> + "skb_segment: "
> + "illegal GSO fragment: %u %u\n",
Don't break up the message -- chekpatch.pl should allow that...
> @@ -2929,7 +2937,15 @@ struct sk_buff *skb_segment(struct sk_buff *skb, netdev_features_t features)
> if (pos < offset + len) {
> struct sk_buff *fskb2 = fskb;
>
> - BUG_ON(pos + fskb->len != offset + len);
> + if (pos + fskb->len != offset + len) {
> + net_warn_ratelimited(
> + "skb_segment: "
> + "illegal GSO trailer: %u %u\n",
Same here.
WBR, Sergei
^ permalink raw reply
* [PATCH] Fix "ip rule delete table 256"
From: Andreas Henriksson @ 2013-11-07 17:26 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, shemminger
When trying to delete a table >= 256 using iproute2 the local table
will be deleted.
The table id is specified as a netlink attribute when it needs more then
8 bits and iproute2 then sets the table field to RT_TABLE_UNSPEC (0).
Preconditions to matching the table id in the rule delete code
doesn't seem to take the "table id in netlink attribute" into condition
so the frh_get_table helper function never gets to do its job when
matching against current rule.
Use the helper function twice instead of peaking at the table value directly.
Originally reported at: http://bugs.debian.org/724783
Reported-by: Nicolas HICHER <nhicher@avencall.com>
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
---
net/core/fib_rules.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
An alternative would be to say RT_TABLE_UNSPEC is incorrect value
to use for the rule->table when using the netlink attribute and
change iproute2 instead....
... but RT_TABLE_UNSPEC sounds quite suitable, so why not
change the kernel to be more forgiving.
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index 2e65413..f409e0b 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -460,7 +460,8 @@ static int fib_nl_delrule(struct sk_buff *skb, struct nlmsghdr* nlh)
if (frh->action && (frh->action != rule->action))
continue;
- if (frh->table && (frh_get_table(frh, tb) != rule->table))
+ if (frh_get_table(frh, tb) &&
+ (frh_get_table(frh, tb) != rule->table))
continue;
if (tb[FRA_PRIORITY] &&
--
1.8.4.2
^ permalink raw reply related
* [PATCH] usb: xhci: Link TRB must not occur with a USB payload burst.
From: David Laight @ 2013-11-07 17:20 UTC (permalink / raw)
To: netdev, linux-usb, Sarah Sharp
Section 4.11.7.1 of rev 1.0 of the xhci specification states that a link TRB
can only occur at a boundary between underlying USB frames (512 bytes for 480M).
If this isn't done the USB frames aren't formatted correctly and, for example,
the USB3 ethernet ax88179_178a card will stop sending (while still receiving)
when running a netperf tcp transmit test with (say) and 8k buffer.
While this change improves things a lot (it runs for 20 minutes rather than
a few seconds), there is still something else wrong.
This should be a candidate for stable, the ax88179_178a driver defaults to
gso and tso enabled so it passes a lot of fragmented skb to the USB stack.
Signed-off-by: David Laight <david.laight@aculab.com>
---
Although I've got a USB2 analyser its trigger and trace stuff is almost
unusable! In any case this fails much faster on USB3 (Intel i7 cpu).
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 5480215..23abc9b 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2927,8 +2932,43 @@ static int prepare_ring(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
}
while (1) {
- if (room_on_ring(xhci, ep_ring, num_trbs))
- break;
+ if (room_on_ring(xhci, ep_ring, num_trbs)) {
+ union xhci_trb *trb = ep_ring->enqueue;
+ unsigned int usable = ep_ring->enq_seg->trbs +
+ TRBS_PER_SEGMENT - 1 - trb;
+ u32 nop_cmd;
+
+ /*
+ * Section 4.11.7.1 TD Fragments states that a link
+ * TRB must only occur at the boundary between
+ * data bursts (eg 512 bytes for 480M).
+ * While it is possible to split a large fragment
+ * we don't know the size yet.
+ * Simplest solution is to fill the trb before the
+ * LINK with nop commands.
+ */
+ if (num_trbs == 1 || num_trbs <= usable || usable == 0)
+ break;
+
+ if (num_trbs >= TRBS_PER_SEGMENT) {
+ xhci_err(xhci, "Too many fragments %d, max %d\n",
+ num_trbs, TRBS_PER_SEGMENT - 1);
+ return -ENOMEM;
+ }
+
+ nop_cmd = cpu_to_le32(TRB_TYPE(TRB_TR_NOOP) |
+ ep_ring->cycle_state);
+ for (; !TRB_TYPE_LINK_LE32(trb->link.control); trb++) {
+ trb->generic.field[0] = 0;
+ trb->generic.field[1] = 0;
+ trb->generic.field[2] = 0;
+ trb->generic.field[3] = nop_cmd;
+ ep_ring->num_trbs_free--;
+ }
+ ep_ring->enqueue = trb;
+ if (room_on_ring(xhci, ep_ring, num_trbs))
+ break;
+ }
if (ep_ring == xhci->cmd_ring) {
xhci_err(xhci, "Do not support expand command ring\n");
^ permalink raw reply related
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