* Re: [PATCH RFC 3/5] net:stmmac: ensure we reclaim all dirty descriptors.
From: Eric Dumazet @ 2013-10-21 18:49 UTC (permalink / raw)
To: Jimmy PERCHET; +Cc: Giuseppe CAVALLARO, netdev
In-Reply-To: <1382380327.3284.77.camel@edumazet-glaptop.roam.corp.google.com>
On Mon, 2013-10-21 at 11:32 -0700, Eric Dumazet wrote:
> On Mon, 2013-10-21 at 15:10 +0200, Jimmy PERCHET wrote:
> > Hello Peppe,
> >
>
> > I can reproduce this problem by issuing 9KiB jumbo frames on 10MBit/s link.
> > If socket's wmemory size is about 500kiB (or less), the transfer stall.
> > (I guess it is reproducible with 1500o frames by decreasing
> > socket's wmemory to 90KB)
> > Re-arming the timer fix this behaviour.
> >
> > Here my understanding of this issue :
> > With 9KiB frames and 500kiB of wmemory, only 60 frames can be
> > prepared in a row. It is below the tx coalescence threshold,
> > so there will be no interrupt. When the tx coalescence timer
> > expires (40ms after), only five descriptors have to be
> > freed (9000*5 @ 10Mbit/s = 34ms), it is not enough to reach
> > the socket's wake-up threshold. We get into a deadlock :
> > *Socket is waiting for free buffers before performing new transfer.
> > *Driver is waiting for new transfer before performing cleanup.
> >
> > Maybe, it is not a real life use-case, and is not worth
> > a patch. What do you think ?
> >
>
> I think there is probably a bug in the driver, a race of some sort,
> and it would be better to find it and fix it ;)
>
coalesce params should not be hardcoded, but depend on link speed and
mtu.
On 10Mbits, and MTU=9000 there is really no point using coalescing !
^ permalink raw reply
* Re: [PATCH] can: add Renesas R-Car CAN driver
From: Wolfgang Grandegger @ 2013-10-21 19:12 UTC (permalink / raw)
To: Sergei Shtylyov, netdev, mkl, linux-can; +Cc: linux-sh, vksavl
In-Reply-To: <526061BE.7060204@cogentembedded.com>
Hi Sergei,
On 10/18/2013 12:16 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 10/02/2013 10:09 AM, Wolfgang Grandegger wrote:
>
> Sorry for the belated reply -- was on vacations.
>
>> thanks for your contribution. The patch looks already quite good. Before
>> I find time for a detailed review could you please check error handling
>> and bus-off recovery by reporting the output of "$ candump -td -e
>> any,0:0,#FFFFFFFF" while sending messages to the device ...
>
>> 1. ... without cable connected
>
> Terminal 1:
>
> root@10.0.0.101:/opt/can-utils# ./cangen -n 1 -g 1 can0
> root@10.0.0.101:/opt/can-utils#
>
> Terminal 2:
>
> root@10.0.0.101:/opt/can-utils# ./candump -td -e any,0:0,#FFFFFFFF
> (000.000000) can0 200000AC [8] 00 08 00 19 00 00 00 00 ERRORFRAME
> controller-problem{tx-error-warning}
> protocol-violation{{}{acknowledge-slot}}
> no-acknowledgement-on-tx
> bus-error
> (000.004496) can0 20000004 [8] 00 20 00 00 00 00 00 00 ERRORFRAME
> controller-problem{tx-error-passive}
>
> So we get and stay in error- passive state:
Looks good.
>
> root@10.0.0.101:/opt/can-utils# ip -details link show can0
> 2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN
> qlen 10 link/can
> can state ERROR-PASSIVE (berr-counter tx 128 rx 0) restart-ms 0
> bitrate 297619 sample-point 0.714
Strange, what bitrate did you configure?
> tq 480 prop-seg 2 phase-seg1 2 phase-seg2 2 sjw 1
> rcar_can: tseg1 4..16 tseg2 2..8 sjw 1..4 brp 1..1024 brp-inc 1
> clock 49999999
Could you please try if the algorithm works better with 50000000.
> root@10.0.0.101:/opt/can-utils#
>
> dmesg:
> rcar_can rcar_can.0 can0: bitrate error 0.7%
> rcar_can rcar_can.0 can0: Error warning interrupt
> rcar_can rcar_can.0 can0: Bus error interrupt:
> rcar_can rcar_can.0 can0: ACK Error
> rcar_can rcar_can.0 can0: Error passive interrupt
>
>> 2. ... with short-circuited CAN high and low and doing some time later
>> a manual recovery with "ip link set can0 type can restart"
>
> Now we have auto recovery only. Manual recovery was tested with the
> first driver version and worked.
What do you mean with "auto recovery"? Auto recovery by the hardware or
via "restart-ms <ms>"? How do you choose between "manual" and "auto"
recovery?
> Terminal 1:
>
> root@10.0.0.104:/opt/can-utils# ./cangen -n 1 -g 1 can0
> root@10.0.0.104:/opt/can-utils# ./cangen -n 1 -g 1 can0
> root@10.0.0.104:/opt/can-utils# ./cangen -n 1 -g 1 can0
> root@10.0.0.104:/opt/can-utils#
>
> Terminal 2:
>
> root@10.0.0.104:/opt/can-utils# ./candump -td -e any,0:0,#FFFFFFFF
> (000.000000) can0 2000008C [8] 00 00 08 00 00 00 00 00 ERRORFRAME
> controller-problem{}
> protocol-violation{{tx-dominant-bit-error}{}}
> bus-error
> (000.021147) can0 20000144 [8] 00 00 00 00 00 00 00 00 ERRORFRAME
> controller-problem{}
> bus-off
> restarted-after-bus-off
Why does it get "restarted" directly after the bus-off?
> (011.738522) can0 2000008C [8] 00 00 08 00 00 00 00 00 ERRORFRAME
> controller-problem{}
What controller problem? data[1] is not set for some reasom.
> protocol-violation{{tx-dominant-bit-error}{}}
> bus-error
> (000.021163) can0 20000144 [8] 00 00 00 00 00 00 00 00 ERRORFRAME
> controller-problem{}
> bus-off
> restarted-after-bus-off
> (001.666625) can0 2000008C [8] 00 00 08 00 00 00 00 00 ERRORFRAME
> controller-problem{}
> protocol-violation{{tx-dominant-bit-error}{}}
> bus-error
> (000.021157) can0 20000144 [8] 00 00 00 00 00 00 00 00 ERRORFRAME
> controller-problem{}
> bus-off
> restarted-after-bus-off
>
> dmesg:
> rcar_can rcar_can.0 can0: Error warning interrupt
> rcar_can rcar_can.0 can0: Error passive interrupt
> rcar_can rcar_can.0 can0: Bus error interrupt:
> rcar_can rcar_can.0 can0: Bit Error (dominant)
> rcar_can rcar_can.0 can0: Error warning interrupt
> rcar_can rcar_can.0 can0: Error passive interrupt
Why are they reported again. You are already in error passive.
> rcar_can rcar_can.0 can0: Bus-off entry interrupt
> rcar_can rcar_can.0 can0: bus-off
> rcar_can rcar_can.0 can0: Bus-off recovery interrupt
> rcar_can rcar_can.0 can0: Error warning interrupt
> rcar_can rcar_can.0 can0: Error passive interrupt
> rcar_can rcar_can.0 can0: Bus error interrupt:
> rcar_can rcar_can.0 can0: Bit Error (dominant)
> rcar_can rcar_can.0 can0: Error warning interrupt
> rcar_can rcar_can.0 can0: Error passive interrupt
> rcar_can rcar_can.0 can0: Bus-off entry interrupt
> rcar_can rcar_can.0 can0: bus-off
> rcar_can rcar_can.0 can0: Bus-off recovery interrupt
> rcar_can rcar_can.0 can0: Error warning interrupt
> rcar_can rcar_can.0 can0: Error passive interrupt
> rcar_can rcar_can.0 can0: Bus error interrupt:
> rcar_can rcar_can.0 can0: Bit Error (dominant)
> rcar_can rcar_can.0 can0: Error warning interrupt
> rcar_can rcar_can.0 can0: Error passive interrupt
> rcar_can rcar_can.0 can0: Bus-off entry interrupt
> rcar_can rcar_can.0 can0: bus-off
> rcar_can rcar_can.0 can0: Bus-off recovery interrupt
>> I also wonder if the messages are always sent in order. You could use
>> the program "canfdtest" [1] from the can-utils for validation.
>
> This program is PITA. With the driver workaroung it works:
What workaround?
Wolfgang.
^ permalink raw reply
* [PATCH net] tcp: initialize passive-side sk_pacing_rate after 3WHS
From: Neal Cardwell @ 2013-10-21 19:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Neal Cardwell, Eric Dumazet, Yuchung Cheng
For passive TCP connections, upon receiving the ACK that completes the
3WHS, make sure we set our pacing rate after we get our first RTT
sample.
On passive TCP connections, when we receive the ACK completing the
3WHS we do not take an RTT sample in tcp_ack(), but rather in
tcp_synack_rtt_meas(). So upon receiving the ACK that completes the
3WHS, tcp_ack() leaves sk_pacing_rate at its initial value.
Originally the initial sk_pacing_rate value was 0, so passive-side
connections defaulted to sysctl_tcp_min_tso_segs (2 segs) in skbuffs
made in the first RTT. With a default initial cwnd of 10 packets, this
happened to be correct for RTTs 5ms or bigger, so it was hard to
see problems in WAN or emulated WAN testing.
Since 7eec4174ff ("pkt_sched: fq: fix non TCP flows pacing"), the
initial sk_pacing_rate is 0xffffffff. So after that change, passive
TCP connections were keeping this value (and using large numbers of
segments per skbuff) until receiving an ACK for data.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
---
net/ipv4/tcp_input.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 53974c7..a16b01b 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5712,6 +5712,8 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb,
} else
tcp_init_metrics(sk);
+ tcp_update_pacing_rate(sk);
+
/* Prevent spurious tcp_cwnd_restart() on first data packet */
tp->lsndtime = tcp_time_stamp;
--
1.8.4
^ permalink raw reply related
* Re: [PATCH net 0/3] ipv6: use rt6i_gateway as nexthop
From: Julian Anastasov @ 2013-10-21 20:02 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: David Miller, netdev, netfilter-devel, lvs-devel,
Hideaki YOSHIFUJI
In-Reply-To: <20131021093541.GG28333@order.stressinduktion.org>
Hello,
On Mon, 21 Oct 2013, Hannes Frederic Sowa wrote:
> Not related to the patch:
>
> That reminds me that Yoshifuji had the idea to cache the results for
> ipv6_addr_type in IP6CB to avoid calling this function over and over again.
> Maybe we can do the same for rt6_infos to save some cycles here and there.
Yes, ipv6_addr_type has little price. May be only
DNAT and IPSec can complicate such caching.
> Also, what do you think about this site:
>
> net/ipv6/ip6_output.c:
> 411
> 412 rt = (struct rt6_info *) dst;
> 413 if (rt->rt6i_flags & RTF_GATEWAY)
> 414 target = &rt->rt6i_gateway;
> 415 else
> 416 target = &hdr->daddr;
> 417
>
> Our provided skb_dst should come from ip6_route_input, thus ip6_pol_route. So
> I assume we have rt6i_gateway == hdr->daddr there, too. It is a bit more
> complicated because of possible routing extension headers. Maybe you already
> looked at this already?
Yes, I checked every site that uses rt6i_gateway but
not with the perspective to use rt6_nexthop(). It seems
this is a rt6_nexthop() candidate.
> I just found it while searching which other code paths do emit packets
> while xt_TEE is processing (generation of redirects) and could also lead
> to stack exhaustion. But the path in ip6_forward seems fine.
Yes. I found only one place more dangerous:
fib6_add_rt2node(). But I think its checks are still valid.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH v2.44 2/5] ofp-actions: Add separate OpenFlow 1.3 action parser
From: Ben Pfaff @ 2013-10-21 20:19 UTC (permalink / raw)
To: Simon Horman
Cc: dev, netdev, Jesse Gross, Pravin B Shelar, Ravi K, Isaku Yamahata,
Joe Stringer
In-Reply-To: <1381972511-27221-3-git-send-email-horms@verge.net.au>
On Thu, Oct 17, 2013 at 10:15:08AM +0900, Simon Horman wrote:
> From: Joe Stringer <joe@wand.net.nz>
>
> This patch adds new ofpact_from_openflow13() and
> ofpacts_from_openflow13() functions parallel to the existing ofpact
> handling code. In the OpenFlow 1.3 version, push_mpls is handled
> differently, but all other actions are handled by the existing code.
>
> In the case of push_mpls for OpenFlow 1.3 the new mpls_before_vlan field of
> struct ofpact_push_mpls is set to true. This will be used by a subsequent
> patch to allow allow the correct VLAN+MPLS datapath behaviour to be
> determined at odp translation time.
>
> enum ofpact_mpls_position contributed by Ben Pfaff.
>
> Signed-off-by: Joe Stringer <joe@wand.net.nz>
> Signed-off-by: Simon Horman <horms@verge.net.au>
I applied this commit to master, but I changed the commit message to:
>From a7a2d006baae4152d338bd0bb4de1687084b1b07 Mon Sep 17 00:00:00 2001
From: Joe Stringer <joe@wand.net.nz>
Date: Thu, 17 Oct 2013 10:15:08 +0900
Subject: [PATCH] ofp-actions: Distinguish OF1.1/1.2 push_mpls from OF1.3+.
In OpenFlow 1.1 and 1.2, the push_mpls action pushes the MPLS label after
any existing VLAN tag. In OpenFlow 1.3, it pushes the label before any
existing VLAN tag. Until now, the action parser didn't distinguish these
cases. This commit adds support. Nothing yet actually changes the
behavior of push_mpls.
enum ofpact_mpls_position contributed by Ben Pfaff.
Signed-off-by: Joe Stringer <joe@wand.net.nz>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Ben Pfaff <blp@nicira.com>
^ permalink raw reply
* Re: [patch net v2 0/3] UFO fixes
From: David Miller @ 2013-10-21 20:26 UTC (permalink / raw)
To: hannes
Cc: jiri, netdev, eric.dumazet, jdmason, yoshfuji, kuznet, jmorris,
kaber, herbert
In-Reply-To: <20131020032617.GA27787@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Sun, 20 Oct 2013 05:26:17 +0200
> Hi David!
>
> On Sat, Oct 19, 2013 at 07:21:47PM -0400, David Miller wrote:
>> From: Jiri Pirko <jiri@resnulli.us>
>> Date: Sat, 19 Oct 2013 12:29:14 +0200
>>
>> > Couple of patches fixing UFO functionality in different situations.
>> >
>> > v1->v2:
>> > - minor if{}else{} coding style adjustment suggested by Sergei Shtylyov
>>
>> Series applied, thanks Jiri.
>
> I would propose that the patches
>
> "ip6_output: do skb ufo init for peeked non ufo skb as well"
> (c547dbf55d5f8cf615ccc0e7265e98db27d3fb8b)
>
> and
>
> "ip_output: do skb ufo init for peeked non ufo skb as well"
> (e93b7d748be887cd7639b113ba7d7ef792a7efb9)
>
> should go to stable because they solve a possible memory corruption
> from userspace.
I suppose... the reason I didn't automatically queue these up for -stable
is that they are rather non-trivial.
^ permalink raw reply
* Re: [PATCH net-next] net: fix build warnings because of net_get_random_once merge
From: David Miller @ 2013-10-21 20:27 UTC (permalink / raw)
To: hannes; +Cc: netdev, linux-kernel
In-Reply-To: <20131020042602.GC27787@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Sun, 20 Oct 2013 06:26:02 +0200
> This patch fixes the following warning:
>
> In file included from include/linux/skbuff.h:27:0,
> from include/linux/netfilter.h:5,
> from include/net/netns/netfilter.h:5,
> from include/net/net_namespace.h:20,
> from include/linux/init_task.h:14,
> from init/init_task.c:1:
> include/linux/net.h:243:14: warning: 'struct static_key' declared inside parameter list [enabled by default]
> struct static_key *done_key);
>
> on x86_64 allnoconfig, um defconfig and ia64 allmodconfig and maybe others as well.
>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Applied, thanks Hannes.
^ permalink raw reply
* Re: [PATCHSET net-next v2 00/07] Support for byte queue limits on various drivers
From: David Miller @ 2013-10-21 20:34 UTC (permalink / raw)
To: milky-kernel; +Cc: netdev
In-Reply-To: <1382292803-18875-1-git-send-email-milky-kernel@mcmilk.de>
I'm not applying any patches that add module parameters for this, sorry.
^ permalink raw reply
* Re: [PATCH net] tcp: initialize passive-side sk_pacing_rate after 3WHS
From: Eric Dumazet @ 2013-10-21 20:36 UTC (permalink / raw)
To: Neal Cardwell; +Cc: David Miller, netdev, Eric Dumazet, Yuchung Cheng
In-Reply-To: <1382384419-6081-1-git-send-email-ncardwell@google.com>
On Mon, 2013-10-21 at 15:40 -0400, Neal Cardwell wrote:
> For passive TCP connections, upon receiving the ACK that completes the
> 3WHS, make sure we set our pacing rate after we get our first RTT
> sample.
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> ---
> net/ipv4/tcp_input.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 53974c7..a16b01b 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -5712,6 +5712,8 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb,
> } else
> tcp_init_metrics(sk);
>
> + tcp_update_pacing_rate(sk);
> +
> /* Prevent spurious tcp_cwnd_restart() on first data packet */
> tp->lsndtime = tcp_time_stamp;
>
Seems good to me, thanks !
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH v2.44 1/5] odp: Allow VLAN actions after MPLS actions
From: Ben Pfaff @ 2013-10-21 20:41 UTC (permalink / raw)
To: Simon Horman
Cc: dev, netdev, Jesse Gross, Pravin B Shelar, Ravi K, Isaku Yamahata,
Joe Stringer
In-Reply-To: <1381972511-27221-2-git-send-email-horms@verge.net.au>
On Thu, Oct 17, 2013 at 10:15:07AM +0900, Simon Horman wrote:
> From: Joe Stringer <joe@wand.net.nz>
>
> OpenFlow 1.1 and 1.2, and 1.3 differ in their handling of MPLS actions in the
> presence of VLAN tags. To allow correct behaviour to be committed in
> each situation, this patch adds a second round of VLAN tag action
> handling to commit_odp_actions(), which occurs after MPLS actions. This
> is implemented with a new field in 'struct xlate_in' called 'vlan_tci'.
>
> When an push_mpls action is composed, the flow's current VLAN state is
> stored into xin->vlan_tci, and flow->vlan_tci is set to 0 (pop_vlan). If
> a VLAN tag is present, it is stripped; if not, then there is no change.
> Any later modifications to the VLAN state is written to xin->vlan_tci.
> When committing the actions, flow->vlan_tci is used before MPLS actions,
> and xin->vlan_tci is used afterwards. This retains the current datapath
> behaviour, but allows VLAN actions to be applied in a more flexible
> manner.
>
> Both before and after this patch MPLS LSEs are pushed onto a packet after
> any VLAN tags that may be present. This is the behaviour described in
> OpenFlow 1.1 and 1.2. OpenFlow 1.3 specifies that MPLS LSEs should be
> pushed onto a packet before any VLAN tags that are present. Support
> for this will be added by a subsequent patch that makes use of
> the infrastructure added by this patch.
>
> Signed-off-by: Joe Stringer <joe@wand.net.nz>
> Signed-off-by: Simon Horman <horms@verge.net.au>
I think that this patch tries to track the VLAN tag inside the MPLS
label and the VLAN tag outside the MPLS label separately. But it does
it in an odd way, by testing whether those tags have the same value.
I'm not sure that's correct. If I set a VLAN, push an MPLS label
outside the VLAN, then push the same VLAN outside the MPLS label, does
it behave correctly? (Is there a test for this behavior in patch 3?
If so then I'm reassured.)
^ permalink raw reply
* Re: [patch net v2 0/3] UFO fixes
From: Hannes Frederic Sowa @ 2013-10-21 21:14 UTC (permalink / raw)
To: David Miller
Cc: jiri, netdev, eric.dumazet, jdmason, yoshfuji, kuznet, jmorris,
kaber, herbert
In-Reply-To: <20131021.162612.1795347771078720888.davem@davemloft.net>
On Mon, Oct 21, 2013 at 04:26:12PM -0400, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Sun, 20 Oct 2013 05:26:17 +0200
>
> > Hi David!
> >
> > On Sat, Oct 19, 2013 at 07:21:47PM -0400, David Miller wrote:
> >> From: Jiri Pirko <jiri@resnulli.us>
> >> Date: Sat, 19 Oct 2013 12:29:14 +0200
> >>
> >> > Couple of patches fixing UFO functionality in different situations.
> >> >
> >> > v1->v2:
> >> > - minor if{}else{} coding style adjustment suggested by Sergei Shtylyov
> >>
> >> Series applied, thanks Jiri.
> >
> > I would propose that the patches
> >
> > "ip6_output: do skb ufo init for peeked non ufo skb as well"
> > (c547dbf55d5f8cf615ccc0e7265e98db27d3fb8b)
> >
> > and
> >
> > "ip_output: do skb ufo init for peeked non ufo skb as well"
> > (e93b7d748be887cd7639b113ba7d7ef792a7efb9)
> >
> > should go to stable because they solve a possible memory corruption
> > from userspace.
>
> I suppose... the reason I didn't automatically queue these up for -stable
> is that they are rather non-trivial.
This patch I proposed before is IMHO more simple. Would you consider
this a candidate for stable only? I would send a proper patch then.
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 6d56840..3565450 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1308,6 +1308,11 @@ static inline int skb_pagelen(const struct sk_buff *skb)
return len + skb_headlen(skb);
}
+static inline bool skb_has_frags(const struct sk_buff *skb)
+{
+ return skb_shinfo(skb)->nr_frags;
+}
+
/**
* __skb_fill_page_desc - initialise a paged fragment in an skb
* @skb: buffer containing fragment to be initialised
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 7d8357b..8dc3d8d 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -836,7 +836,7 @@ static int __ip_append_data(struct sock *sk,
csummode = CHECKSUM_PARTIAL;
cork->length += length;
- if (((length > mtu) || (skb && skb_is_gso(skb))) &&
+ if (((length > mtu) || (skb && skb_has_frags(skb))) &&
(sk->sk_protocol == IPPROTO_UDP) &&
(rt->dst.dev->features & NETIF_F_UFO) && !rt->dst.header_len) {
err = ip_ufo_append_data(sk, queue, getfrag, from, length,
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index a54c45c..ded4f6f 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1227,7 +1227,7 @@ int ip6_append_data(struct sock *sk, int getfrag(void *from, char *to,
skb = skb_peek_tail(&sk->sk_write_queue);
cork->length += length;
if (((length > mtu) ||
- (skb && skb_is_gso(skb))) &&
+ (skb && skb_has_frags(skb))) &&
(sk->sk_protocol == IPPROTO_UDP) &&
(rt->dst.dev->features & NETIF_F_UFO)) {
err = ip6_ufo_append_data(sk, getfrag, from, length,
Greetings,
Hannes
^ permalink raw reply related
* Re: [patch net v2 0/3] UFO fixes
From: David Miller @ 2013-10-21 21:15 UTC (permalink / raw)
To: hannes
Cc: jiri, netdev, eric.dumazet, jdmason, yoshfuji, kuznet, jmorris,
kaber, herbert
In-Reply-To: <20131021211426.GB24158@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Mon, 21 Oct 2013 23:14:26 +0200
> This patch I proposed before is IMHO more simple. Would you consider
> this a candidate for stable only? I would send a proper patch then.
Yes, I would.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] net: remove function sk_reset_txq()
From: David Miller @ 2013-10-21 21:18 UTC (permalink / raw)
To: gamerh2o; +Cc: netdev, linux-kernel
In-Reply-To: <20131020013757.GA25265@will>
From: ZHAO Gang <gamerh2o@gmail.com>
Date: Sun, 20 Oct 2013 09:37:57 +0800
> What sk_reset_txq() does is just calls function sk_tx_queue_reset(),
> and sk_reset_txq() is used only in sock.h, by dst_negative_advice().
> Let dst_negative_advice() calls sk_tx_queue_reset() directly so we
> can remove unneeded sk_reset_txq().
>
> Signed-off-by: ZHAO Gang <gamerh2o@gmail.com>
> change a typo in patch description: sock.c -> sock.h
This patch does not apply cleanly to net-next, please fix this up
and resubmit.
Thanks.
^ permalink raw reply
* Re: nf_tables*.h: Remove extern from function prototypes
From: David Miller @ 2013-10-21 21:19 UTC (permalink / raw)
To: joe; +Cc: netdev, linux-kernel
In-Reply-To: <1382245531.2041.37.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Sat, 19 Oct 2013 22:05:31 -0700
> There are a mix of function prototypes with and without extern
> in the kernel sources. Standardize on not using extern for
> function prototypes.
>
> Function prototypes don't need to be written with extern.
> extern is assumed by the compiler. Its use is as unnecessary as
> using auto to declare automatic/local variables in a block.
>
> Signed-off-by: Joe Perches <joe@perches.com>
I'll apply this directly, thanks Joe.
^ permalink raw reply
* Re: [PATCH 00/15] net: ethernet: remove unnecessary pci_set_drvdata() part 2
From: David Miller @ 2013-10-21 21:21 UTC (permalink / raw)
To: jg1.han; +Cc: netdev
In-Reply-To: <003801cece02$6abb0160$40310420$%han@samsung.com>
From: Jingoo Han <jg1.han@samsung.com>
Date: Mon, 21 Oct 2013 11:08:21 +0900
> Since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
> (device-core: Ensure drvdata = NULL when no driver is bound),
> the driver core clears the driver data to NULL after device_release
> or on probe failure. Thus, it is not needed to manually clear the
> device driver data to NULL.
Series applied, thanks.
^ permalink raw reply
* Re: [net PATCH 1/1] drivers: net: cpsw: fix kernel warn during iperf test with interrupt pacing
From: David Miller @ 2013-10-21 21:23 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev, linux-omap, bigeasy
In-Reply-To: <1382252546-16382-1-git-send-email-mugunthanvnm@ti.com>
From: Mugunthan V N <mugunthanvnm@ti.com>
Date: Sun, 20 Oct 2013 12:32:26 +0530
> When interrupt pacing is enabled, receive/transmit statistics are not
> updated properly by hardware which leads to ISR return with IRQ_NONE
> and inturn kernel disables the interrupt. This patch removed the checking
> of receive/transmit statistics from ISR.
>
> This patch is verified with AM335x Beagle Bone Black and below is the
> kernel warn when interrupt pacing is enabled.
...
> Cc: Sebastian Siewior <bigeasy@linutronix.de>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Applied, thanks.
^ permalink raw reply
* [net-next PATCH] macvlan: resolve ENOENT errors on creation
From: John Fastabend @ 2013-10-21 21:28 UTC (permalink / raw)
To: vfalico, nhorman; +Cc: netdev
After the commit below attempting to create macvlan devices was
resulting in ENOENT errors,
# ip link add link p3p2 type macvlan
RTNETLINK answers: Invalid argument
This happens because netdev_upper_dev_link() is called before
register_netdevice() in the macvlan code. Through a call chain
this results in a call to __netdev_adjacent_dev_insert() and
finally a sysfs_create_link(). This requires the kobject of
the macvlan to be registered which is done in register_netdevice().
If there is no kobject which is the case here the ENOENT error
is seen on the command line.
To resolve this move the netdev_upper_dev_link() call below
the register_netdevice() call. This aligns with vlan driver
flow.
Regression introduced here,
commit 5831d66e8097aedfa3bc35941cf265ada2352317
Author: Veaceslav Falico <vfalico@redhat.com>
Date: Wed Sep 25 09:20:32 2013 +0200
net: create sysfs symlinks for neighbour devices
CC: Veaceslav Falico <vfalico@redhat.com>
CC: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
---
drivers/net/macvlan.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 9bf46bd..cc9845e 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -828,22 +828,21 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
eth_hw_addr_inherit(dev, lowerdev);
}
+ port->count += 1;
+ err = register_netdevice(dev);
+ if (err < 0)
+ goto destroy_port;
+
err = netdev_upper_dev_link(lowerdev, dev);
if (err)
goto destroy_port;
- port->count += 1;
- err = register_netdevice(dev);
- if (err < 0)
- goto upper_dev_unlink;
list_add_tail_rcu(&vlan->list, &port->vlans);
netif_stacked_transfer_operstate(lowerdev, dev);
return 0;
-upper_dev_unlink:
- netdev_upper_dev_unlink(lowerdev, dev);
destroy_port:
port->count -= 1;
if (!port->count)
^ permalink raw reply related
* [PATCH net] netpoll: linearize skb before accessing its data
From: Antonio Quartulli @ 2013-10-21 21:31 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Antonio Quartulli
__netpoll_rx() assumes that the data buffer of the received
skb is linear and then passes it to rx_hook().
However this is not true because the skb has not been
linearized yet.
This can cause rx_hook() to access non allocated memory
while parsing the received data.
Fix __netpoll_rx() by explicitly linearising the skb.
Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
---
I checked linux-3.0 and this bug seems to be already there. Please consider
queueing it for stable.
Regards,
net/core/netpoll.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index fc75c9e..97cff18 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -814,6 +814,9 @@ int __netpoll_rx(struct sk_buff *skb, struct netpoll_info *npinfo)
if (pskb_trim_rcsum(skb, len))
goto out;
+ if (skb_linearize(skb))
+ goto out;
+
iph = (struct iphdr *)skb->data;
if (iph->protocol != IPPROTO_UDP)
goto out;
@@ -855,6 +858,8 @@ int __netpoll_rx(struct sk_buff *skb, struct netpoll_info *npinfo)
goto out;
if (pskb_trim_rcsum(skb, len + sizeof(struct ipv6hdr)))
goto out;
+ if (skb_linearize(skb))
+ goto out;
ip6h = ipv6_hdr(skb);
if (!pskb_may_pull(skb, sizeof(struct udphdr)))
goto out;
--
1.8.4
^ permalink raw reply related
* Re: [net-next PATCH] macvlan: resolve ENOENT errors on creation
From: Veaceslav Falico @ 2013-10-21 21:34 UTC (permalink / raw)
To: John Fastabend; +Cc: nhorman, netdev
In-Reply-To: <20131021212801.19330.69659.stgit@nitbit.x32>
On Mon, Oct 21, 2013 at 02:28:02PM -0700, John Fastabend wrote:
>After the commit below attempting to create macvlan devices was
>resulting in ENOENT errors,
>
># ip link add link p3p2 type macvlan
>RTNETLINK answers: Invalid argument
>
>This happens because netdev_upper_dev_link() is called before
>register_netdevice() in the macvlan code. Through a call chain
>this results in a call to __netdev_adjacent_dev_insert() and
>finally a sysfs_create_link(). This requires the kobject of
>the macvlan to be registered which is done in register_netdevice().
>If there is no kobject which is the case here the ENOENT error
>is seen on the command line.
>
>To resolve this move the netdev_upper_dev_link() call below
>the register_netdevice() call. This aligns with vlan driver
>flow.
Yep, changed the vlan code, but didn't see the macvlan. My cscope didn't
catch it for some reason :-/.
I've also checked - there are no users except bonding, vlan (both are ok),
and macvlan.
Acked-by: Veaceslav Falico <vfalico@redhat.com>
>
>Regression introduced here,
>
>commit 5831d66e8097aedfa3bc35941cf265ada2352317
>Author: Veaceslav Falico <vfalico@redhat.com>
>Date: Wed Sep 25 09:20:32 2013 +0200
>
> net: create sysfs symlinks for neighbour devices
>
>CC: Veaceslav Falico <vfalico@redhat.com>
>CC: Neil Horman <nhorman@tuxdriver.com>
>Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>---
> drivers/net/macvlan.c | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
>diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>index 9bf46bd..cc9845e 100644
>--- a/drivers/net/macvlan.c
>+++ b/drivers/net/macvlan.c
>@@ -828,22 +828,21 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
> eth_hw_addr_inherit(dev, lowerdev);
> }
>
>+ port->count += 1;
>+ err = register_netdevice(dev);
>+ if (err < 0)
>+ goto destroy_port;
>+
> err = netdev_upper_dev_link(lowerdev, dev);
> if (err)
> goto destroy_port;
>
>- port->count += 1;
>- err = register_netdevice(dev);
>- if (err < 0)
>- goto upper_dev_unlink;
>
> list_add_tail_rcu(&vlan->list, &port->vlans);
> netif_stacked_transfer_operstate(lowerdev, dev);
>
> return 0;
>
>-upper_dev_unlink:
>- netdev_upper_dev_unlink(lowerdev, dev);
> destroy_port:
> port->count -= 1;
> if (!port->count)
>
^ permalink raw reply
* Re: [net-next PATCH] macvlan: resolve ENOENT errors on creation
From: John Fastabend @ 2013-10-21 21:48 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: nhorman, netdev
In-Reply-To: <20131021213441.GB18170@redhat.com>
On 10/21/2013 02:34 PM, Veaceslav Falico wrote:
> On Mon, Oct 21, 2013 at 02:28:02PM -0700, John Fastabend wrote:
>> After the commit below attempting to create macvlan devices was
>> resulting in ENOENT errors,
>>
>> # ip link add link p3p2 type macvlan
>> RTNETLINK answers: Invalid argument
>>
>> This happens because netdev_upper_dev_link() is called before
>> register_netdevice() in the macvlan code. Through a call chain
>> this results in a call to __netdev_adjacent_dev_insert() and
>> finally a sysfs_create_link(). This requires the kobject of
>> the macvlan to be registered which is done in register_netdevice().
>> If there is no kobject which is the case here the ENOENT error
>> is seen on the command line.
>>
>> To resolve this move the netdev_upper_dev_link() call below
>> the register_netdevice() call. This aligns with vlan driver
>> flow.
>
> Yep, changed the vlan code, but didn't see the macvlan. My cscope didn't
> catch it for some reason :-/.
>
> I've also checked - there are no users except bonding, vlan (both are ok),
> and macvlan.
>
The openvswitch code uses netdev_master_upper_dev_link() which
eventually calls __netdev_adjacent_dev_insert() as well. But from
a quick code inspection I think it should work. Anyways that is one
other user.
.John
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [net-next PATCH] macvlan: resolve ENOENT errors on creation
From: Neil Horman @ 2013-10-21 21:54 UTC (permalink / raw)
To: John Fastabend; +Cc: vfalico, netdev
In-Reply-To: <20131021212801.19330.69659.stgit@nitbit.x32>
On Mon, Oct 21, 2013 at 02:28:02PM -0700, John Fastabend wrote:
> After the commit below attempting to create macvlan devices was
> resulting in ENOENT errors,
>
> # ip link add link p3p2 type macvlan
> RTNETLINK answers: Invalid argument
>
> This happens because netdev_upper_dev_link() is called before
> register_netdevice() in the macvlan code. Through a call chain
> this results in a call to __netdev_adjacent_dev_insert() and
> finally a sysfs_create_link(). This requires the kobject of
> the macvlan to be registered which is done in register_netdevice().
> If there is no kobject which is the case here the ENOENT error
> is seen on the command line.
>
> To resolve this move the netdev_upper_dev_link() call below
> the register_netdevice() call. This aligns with vlan driver
> flow.
>
> Regression introduced here,
>
> commit 5831d66e8097aedfa3bc35941cf265ada2352317
> Author: Veaceslav Falico <vfalico@redhat.com>
> Date: Wed Sep 25 09:20:32 2013 +0200
>
> net: create sysfs symlinks for neighbour devices
>
> CC: Veaceslav Falico <vfalico@redhat.com>
> CC: Neil Horman <nhorman@tuxdriver.com>
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* [PATCH] net-bnx2x: Fix byte order problem on NVRAM writes
From: Nate Klein @ 2013-10-21 21:57 UTC (permalink / raw)
To: netdev; +Cc: eilong, nxk, linux-kernel
Tested:
ethtool -e eth0 raw on >first.nvram
ethtool -E eth0 <first.nvram
ethtool -e eth0 raw on >second.nvram
cmp first.nvram second.nvram || ethtool -E eth0 <second.nvram
(No output means pass.)
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
index 8213cc8..35671fb 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c
@@ -1549,7 +1549,7 @@ static int bnx2x_nvram_write_dword(struct bnx2x *bp, u32 offset, u32 val,
REG_WR(bp, MCP_REG_MCPR_NVM_COMMAND, MCPR_NVM_COMMAND_DONE);
/* write the data */
- REG_WR(bp, MCP_REG_MCPR_NVM_WRITE, val);
+ REG_WR(bp, MCP_REG_MCPR_NVM_WRITE, cpu_to_be32(val));
/* address of the NVRAM to write to */
REG_WR(bp, MCP_REG_MCPR_NVM_ADDR,
--
1.8.4
^ permalink raw reply related
* [PATCH stable] inet: fix possible memory corruption with UDP_CORK and UFO
From: Hannes Frederic Sowa @ 2013-10-21 22:07 UTC (permalink / raw)
To: netdev; +Cc: jiri, eric.dumazet, davem
This is a replacement patch only for stable which does fix the problems
handled by the following two commits in -net:
"ip_output: do skb ufo init for peeked non ufo skb as well" (e93b7d748be887cd7639b113ba7d7ef792a7efb9)
"ip6_output: do skb ufo init for peeked non ufo skb as well" (c547dbf55d5f8cf615ccc0e7265e98db27d3fb8b)
Three frames are written on a corked udp socket for which the output
netdevice has UFO enabled. If the first and third frame are smaller than
the mtu and the second one is bigger, we enqueue the second frame with
skb_append_datato_frags without initializing the gso fields. This leads
to the third frame appended regulary and thus constructing an invalid skb.
This fixes the problem by always using skb_append_datato_frags as soon
as the first frag got enqueued to the skb without marking the packet
as SKB_GSO_UDP.
The problem with only two frames for ipv6 was fixed by "ipv6: udp
packets following an UFO enqueued packet need also be handled by UFO"
(2811ebac2521ceac84f2bdae402455baa6a7fb47).
Cc: Jiri Pirko <jiri@resnulli.us>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
include/linux/skbuff.h | 5 +++++
net/ipv4/ip_output.c | 2 +-
net/ipv6/ip6_output.c | 2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index c2d8933..eee3d92 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1316,6 +1316,11 @@ static inline int skb_pagelen(const struct sk_buff *skb)
return len + skb_headlen(skb);
}
+static inline bool skb_has_frags(const struct sk_buff *skb)
+{
+ return skb_shinfo(skb)->nr_frags;
+}
+
/**
* __skb_fill_page_desc - initialise a paged fragment in an skb
* @skb: buffer containing fragment to be initialised
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 3982eab..13e617f 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -841,7 +841,7 @@ static int __ip_append_data(struct sock *sk,
csummode = CHECKSUM_PARTIAL;
cork->length += length;
- if (((length > mtu) || (skb && skb_is_gso(skb))) &&
+ if (((length > mtu) || (skb && skb_has_frags(skb))) &&
(sk->sk_protocol == IPPROTO_UDP) &&
(rt->dst.dev->features & NETIF_F_UFO) && !rt->dst.header_len) {
err = ip_ufo_append_data(sk, queue, getfrag, from, length,
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 975624b..65f28be 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1230,7 +1230,7 @@ int ip6_append_data(struct sock *sk, int getfrag(void *from, char *to,
skb = skb_peek_tail(&sk->sk_write_queue);
cork->length += length;
if (((length > mtu) ||
- (skb && skb_is_gso(skb))) &&
+ (skb && skb_has_frags(skb))) &&
(sk->sk_protocol == IPPROTO_UDP) &&
(rt->dst.dev->features & NETIF_F_UFO)) {
err = ip6_ufo_append_data(sk, getfrag, from, length,
--
1.8.3.1
^ permalink raw reply related
* Re: [net-next PATCH] macvlan: resolve ENOENT errors on creation
From: Veaceslav Falico @ 2013-10-21 22:05 UTC (permalink / raw)
To: John Fastabend; +Cc: nhorman, netdev
In-Reply-To: <5265A147.4010501@gmail.com>
On Mon, Oct 21, 2013 at 02:48:55PM -0700, John Fastabend wrote:
>On 10/21/2013 02:34 PM, Veaceslav Falico wrote:
>>On Mon, Oct 21, 2013 at 02:28:02PM -0700, John Fastabend wrote:
>>>After the commit below attempting to create macvlan devices was
>>>resulting in ENOENT errors,
>>>
>>># ip link add link p3p2 type macvlan
>>>RTNETLINK answers: Invalid argument
>>>
>>>This happens because netdev_upper_dev_link() is called before
>>>register_netdevice() in the macvlan code. Through a call chain
>>>this results in a call to __netdev_adjacent_dev_insert() and
>>>finally a sysfs_create_link(). This requires the kobject of
>>>the macvlan to be registered which is done in register_netdevice().
>>>If there is no kobject which is the case here the ENOENT error
>>>is seen on the command line.
>>>
>>>To resolve this move the netdev_upper_dev_link() call below
>>>the register_netdevice() call. This aligns with vlan driver
>>>flow.
>>
>>Yep, changed the vlan code, but didn't see the macvlan. My cscope didn't
>>catch it for some reason :-/.
>>
>>I've also checked - there are no users except bonding, vlan (both are ok),
>>and macvlan.
>>
>
>The openvswitch code uses netdev_master_upper_dev_link() which
>eventually calls __netdev_adjacent_dev_insert() as well. But from
>a quick code inspection I think it should work. Anyways that is one
>other user.
Yep, checked them also now:
team - links two already existing devices (team->dev and port_dev)
batadv - links existing device to another existing device, or creates of if
the latter doesn't exist (and calls register_netdev on creation)
bridge - links two already existing devices (bridge->dev and dev)
openvswitch - links two already existing devices (get_dpdev(vport->dp) and
the device found by dev_get_by_name()).
bonding - uses netdev_master_upper_dev_link_private(), and is also ok.
Hopefully we're safe.
>
>.John
>
>--
>John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH net] netpoll: linearize skb before accessing its data
From: David Miller @ 2013-10-21 22:23 UTC (permalink / raw)
To: antonio; +Cc: netdev
In-Reply-To: <1382391080-1607-1-git-send-email-antonio@meshcoding.com>
From: Antonio Quartulli <antonio@meshcoding.com>
Date: Mon, 21 Oct 2013 23:31:20 +0200
> __netpoll_rx() assumes that the data buffer of the received
> skb is linear and then passes it to rx_hook().
> However this is not true because the skb has not been
> linearized yet.
>
> This can cause rx_hook() to access non allocated memory
> while parsing the received data.
>
> Fix __netpoll_rx() by explicitly linearising the skb.
>
> Signed-off-by: Antonio Quartulli <antonio@meshcoding.com>
It is rx_hook's obligation to access the SKB properly and not
assume that the SKB is linear. It is very expensive to
linearize every SKB just for the sake of improperly implemented
receive hooks.
In particular the rx hooks must make use of interface such
as pskb_may_pull(), just like every other protocol does
on packet input processing, to make sure the area they want
to access is in the linear area.
^ 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