* Re: [PATCH v2] net/macb: fix sparse warning
From: David Miller @ 2015-02-06 0:06 UTC (permalink / raw)
To: prabhakar.csengg; +Cc: nicolas.ferre, netdev, linux-kernel
In-Reply-To: <1423153267-1768-1-git-send-email-prabhakar.csengg@gmail.com>
From: Lad Prabhakar <prabhakar.csengg@gmail.com>
Date: Thu, 5 Feb 2015 16:21:07 +0000
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warning:
>
> macb.c:2038:26: warning: symbol 'gem_ethtool_ops' was not declared. Should it be static?
>
> Alongside drops exporting of gem_ethtool_ops as there is no need.
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: bnx2x: fix sparse warnings
From: David Miller @ 2015-02-06 0:05 UTC (permalink / raw)
To: prabhakar.csengg; +Cc: ariel.elior, netdev, linux-kernel
In-Reply-To: <1423151237-20746-1-git-send-email-prabhakar.csengg@gmail.com>
From: Lad Prabhakar <prabhakar.csengg@gmail.com>
Date: Thu, 5 Feb 2015 15:47:17 +0000
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warnings:
>
> bnx2x_main.c:9172:6: warning: symbol 'bnx2x_stop_ptp' was not declared. Should it be static?
> bnx2x_main.c:13321:6: warning: symbol 'bnx2x_register_phc' was not declared. Should it be static?
> bnx2x_main.c:14638:5: warning: symbol 'bnx2x_enable_ptp_packets' was not declared. Should it be static?
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] enic: enic_main: fix sparse warnings
From: David Miller @ 2015-02-06 0:05 UTC (permalink / raw)
To: prabhakar.csengg; +Cc: benve, ssujith, _govind, neepatel, netdev, linux-kernel
In-Reply-To: <1423150453-26417-1-git-send-email-prabhakar.csengg@gmail.com>
From: Lad Prabhakar <prabhakar.csengg@gmail.com>
Date: Thu, 5 Feb 2015 15:34:13 +0000
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warnings:
>
> enic_main.c:92:28: warning: symbol 'mod_table' was not declared. Should it be static?
> enic_main.c:109:28: warning: symbol 'mod_range' was not declared. Should it be static?
> enic_main.c:1306:5: warning: symbol 'enic_busy_poll' was not declared. Should it be static?
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] enic: enic_ethtool: fix sparse warning
From: David Miller @ 2015-02-06 0:05 UTC (permalink / raw)
To: prabhakar.csengg; +Cc: benve, ssujith, _govind, neepatel, netdev, linux-kernel
In-Reply-To: <1423150195-14742-1-git-send-email-prabhakar.csengg@gmail.com>
From: Lad Prabhakar <prabhakar.csengg@gmail.com>
Date: Thu, 5 Feb 2015 15:29:55 +0000
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warning:
>
> enic_ethtool.c:95:6: warning: symbol 'enic_intr_coal_set_rx' was not declared. Should it be static?
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] be2net: fix sparse warning
From: David Miller @ 2015-02-06 0:05 UTC (permalink / raw)
To: prabhakar.csengg
Cc: sathya.perla, subbu.seetharaman, ajit.khaparde, netdev,
linux-kernel
In-Reply-To: <1423149883-4717-1-git-send-email-prabhakar.csengg@gmail.com>
From: Lad Prabhakar <prabhakar.csengg@gmail.com>
Date: Thu, 5 Feb 2015 15:24:43 +0000
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warning:
>
> be_cmds.c:2750:5: warning: symbol 'be_cmd_set_qos' was not declared. Should it be static?
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] chelsio: cxgb4: fix sparse warning
From: David Miller @ 2015-02-06 0:05 UTC (permalink / raw)
To: prabhakar.csengg; +Cc: hariprasad, netdev, linux-kernel
In-Reply-To: <1423149609-24108-1-git-send-email-prabhakar.csengg@gmail.com>
From: Lad Prabhakar <prabhakar.csengg@gmail.com>
Date: Thu, 5 Feb 2015 15:20:09 +0000
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warning:
>
> cxgb4_dcb.c:25:6: warning: symbol 'dcb_ver_array' was not declared. Should it be static?
>
> Alongside making it const.
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] hyperv: fix sparse warnings
From: David Miller @ 2015-02-06 0:05 UTC (permalink / raw)
To: prabhakar.csengg; +Cc: kys, haiyangz, devel, netdev, linux-kernel
In-Reply-To: <1423148793-19610-1-git-send-email-prabhakar.csengg@gmail.com>
From: Lad Prabhakar <prabhakar.csengg@gmail.com>
Date: Thu, 5 Feb 2015 15:06:33 +0000
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warnings:
>
> netvsc.c:688:5: warning: symbol 'netvsc_copy_to_send_buf' was not declared. Should it be static?
> rndis_filter.c:627:5: warning: symbol 'rndis_filter_set_offload_params' was not declared. Should it be static?
> rndis_filter.c:702:5: warning: symbol 'rndis_filter_set_rss_param' was not declared. Should it be static?
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] xen-netback: fix sparse warning
From: David Miller @ 2015-02-06 0:04 UTC (permalink / raw)
To: prabhakar.csengg; +Cc: ian.campbell, wei.liu2, xen-devel, netdev, linux-kernel
In-Reply-To: <1423143487-4722-1-git-send-email-prabhakar.csengg@gmail.com>
From: Lad Prabhakar <prabhakar.csengg@gmail.com>
Date: Thu, 5 Feb 2015 13:38:07 +0000
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warning:
>
> interface.c:83:5: warning: symbol 'xenvif_poll' was not declared. Should it be static?
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Applied.
^ permalink raw reply
* Re: FW: gre interfaces copied to new namespace
From: Eric W. Biederman @ 2015-02-05 23:58 UTC (permalink / raw)
To: Steve Biggs; +Cc: netdev
In-Reply-To: <EDD8E64855FBDA45ACDFE02112E795B7109CB5DC7A@HQ1-EXCH03.corp.brocade.com>
Steve Biggs <sbiggs@Brocade.com> writes:
> Sorry, forgot to include you as CC. Been a long time since I've posted
> to an open source list, so I'm probably going to make mistakes that
> hopefully won't get me kicked off or start a flame war, as I already
> have as you can see below. :-(
Weird. I haven't seen a copy of this through the netdev mailling list.
> -----Original Message-----
> From: Steve Biggs
> Sent: Thursday, February 05, 2015 3:38 PM
> To: 'netdev@vger.kernel.org'
> Subject: gre interfaces copied to new namespace
>
> (My first post to this list. I forgot to change my settings and I sent
> the previous version of this post using HTML mail. Terribly sorry if
> this caused anybody any problems; won't happen again... it may be that
> it never got to the list at all?)
>
> I am going under the assumption that a newly created network namespace
> should have the loopback (lo) device as its only contents, with it
> being an error to have any other already existing interfaces in the
> default namespace also copied in. If this assumption is wrong, please
> advise and then if so, sorry for the noise.
There may be one or two other devices (tunnels) in a newly created
network namespace whose purpose is to allow the old ioctl tunnel
creation APIs to work.
I think it is silly that we provide the backwards compatibility with the
brand-new gretap interfaces but otherwise I don't see anything to
complain about with the commands you have given.
I thought you said something in here triggered a BUG_ON.
> I was able to reproduce this on a vanilla Debian Wheezy installation
> with the following sequence of commands. Debian Wheezy is running an
> older kernel version, so this is a long-standing issue. I am also able
> to reproduce this on a 3.14.y based kernel.
Before reading the commands below I hadn't realized you could
type "ip a" instead of "ip addr list"
> # ip netns list
> # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> # modprobe ip_gre
> # ip a
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 12: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default
> link/gre 0.0.0.0 brd 0.0.0.0
> 13: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> # ip netns add foo
> # ip netns list foo
> # ip netns exec foo ip a
> 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 2: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default
> link/gre 0.0.0.0 brd 0.0.0.0
> 3: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> # rmmod ip_gre
> # ip netns exec foo ip a
> 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> # ip netns del foo
> # ip netns list
> #
Eric
^ permalink raw reply
* Re: [PATCH net-next 0/9] tipc: resolve message disordering problem
From: David Miller @ 2015-02-06 0:00 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, paul.gortmaker, erik.hugne, ying.xue, maloy,
tipc-discussion
In-Reply-To: <1423143404-23322-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Thu, 5 Feb 2015 08:36:35 -0500
> When TIPC receives messages from multi-threaded device drivers it may
> occasionally deliver messages to their destination sockets in the wrong
> order. This happens despite correct resequencing at the link layer,
> because the upcall path from link to socket is not protected by any
> locks.
>
> These commits solve this problem by introducing an 'input' message
> queue in each link, through which messages must be delivered to the
> upper layers.
Looks good, series applied, thanks Jon.
^ permalink raw reply
* Re: [PATCH net] pktgen: fix UDP checksum computation
From: Tom Herbert @ 2015-02-05 23:57 UTC (permalink / raw)
To: Sabrina Dubroca; +Cc: David Miller, Linux Netdev List, Thomas Graf
In-Reply-To: <1423087730-9201-1-git-send-email-sd@queasysnail.net>
On Wed, Feb 4, 2015 at 2:08 PM, Sabrina Dubroca <sd@queasysnail.net> wrote:
> This patch fixes two issues in UDP checksum computation in pktgen.
>
> First, the pseudo-header uses the source and destination IP
> addresses. Currently, the ports are used for IPv4.
>
> Second, the UDP checksum covers both header and data. So we need to
> generate the data earlier (move pktgen_finalize_skb up), and compute
> the checksum for UDP header + data.
>
> Fixes: c26bf4a51308c ("pktgen: Add UDPCSUM flag to support UDP checksums")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
> ---
> net/core/pktgen.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/net/core/pktgen.c b/net/core/pktgen.c
> index da934fc3faa8..9fa25b0ea145 100644
> --- a/net/core/pktgen.c
> +++ b/net/core/pktgen.c
> @@ -2842,25 +2842,25 @@ static struct sk_buff *fill_packet_ipv4(struct net_device *odev,
> skb->dev = odev;
> skb->pkt_type = PACKET_HOST;
>
> + pktgen_finalize_skb(pkt_dev, skb, datalen);
> +
> if (!(pkt_dev->flags & F_UDPCSUM)) {
> skb->ip_summed = CHECKSUM_NONE;
> } else if (odev->features & NETIF_F_V4_CSUM) {
> skb->ip_summed = CHECKSUM_PARTIAL;
> skb->csum = 0;
> - udp4_hwcsum(skb, udph->source, udph->dest);
> + udp4_hwcsum(skb, iph->saddr, iph->daddr);
> } else {
> - __wsum csum = udp_csum(skb);
> + __wsum csum = skb_checksum(skb, skb_transport_offset(skb), datalen + 8, 0);
>
> /* add protocol-dependent pseudo-header */
> - udph->check = csum_tcpudp_magic(udph->source, udph->dest,
> + udph->check = csum_tcpudp_magic(iph->saddr, iph->daddr,
> datalen + 8, IPPROTO_UDP, csum);
>
> if (udph->check == 0)
> udph->check = CSUM_MANGLED_0;
> }
>
Would it be possible to use udp_set_csum to handle all of this?
Thanks,
Tom
> - pktgen_finalize_skb(pkt_dev, skb, datalen);
> -
> #ifdef CONFIG_XFRM
> if (!process_ipsec(pkt_dev, skb, protocol))
> return NULL;
> @@ -2976,6 +2976,8 @@ static struct sk_buff *fill_packet_ipv6(struct net_device *odev,
> skb->dev = odev;
> skb->pkt_type = PACKET_HOST;
>
> + pktgen_finalize_skb(pkt_dev, skb, datalen);
> +
> if (!(pkt_dev->flags & F_UDPCSUM)) {
> skb->ip_summed = CHECKSUM_NONE;
> } else if (odev->features & NETIF_F_V6_CSUM) {
> @@ -2984,7 +2986,7 @@ static struct sk_buff *fill_packet_ipv6(struct net_device *odev,
> skb->csum_offset = offsetof(struct udphdr, check);
> udph->check = ~csum_ipv6_magic(&iph->saddr, &iph->daddr, udplen, IPPROTO_UDP, 0);
> } else {
> - __wsum csum = udp_csum(skb);
> + __wsum csum = skb_checksum(skb, skb_transport_offset(skb), udplen, 0);
>
> /* add protocol-dependent pseudo-header */
> udph->check = csum_ipv6_magic(&iph->saddr, &iph->daddr, udplen, IPPROTO_UDP, csum);
> @@ -2993,8 +2995,6 @@ static struct sk_buff *fill_packet_ipv6(struct net_device *odev,
> udph->check = CSUM_MANGLED_0;
> }
>
> - pktgen_finalize_skb(pkt_dev, skb, datalen);
> -
> return skb;
> }
>
> --
> 2.2.2
>
> --
> 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 RFC 1/2] ipv6: Fix after pmtu events dissapearing host routes
From: Martin Lau @ 2015-02-05 23:56 UTC (permalink / raw)
To: Steffen Klassert
Cc: Yang Yingliang, netdev, Hannes Frederic Sowa, David S. Miller
In-Reply-To: <20150128121150.GN13046@secunet.com>
On Wed, Jan 28, 2015 at 01:11:51PM +0100, Steffen Klassert wrote:
> We currently don't clone host routes before we use them.
> If a pmtu event is received on such a route, it gets
> an expires value. As soon as the expiration time is
> elapsed, the route is deleted. As a result, the host
> is not reachable any more.
>
> We fix this by cloning host routes if they are gatewayed,
> i.e. if pmtu events can happen.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
> ---
> net/ipv6/route.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index c910831..3e864e7 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -961,7 +961,7 @@ redo_rt6_select:
>
> if (!(rt->rt6i_flags & (RTF_NONEXTHOP | RTF_GATEWAY)))
> nrt = rt6_alloc_cow(rt, &fl6->daddr, &fl6->saddr);
> - else if (!(rt->dst.flags & DST_HOST))
> + else if (!(rt->dst.flags & DST_HOST) || (rt->rt6i_flags & RTF_GATEWAY))
> nrt = rt6_alloc_clone(rt, &fl6->daddr);
The del path may also require changes. I am thinking:
1. Create a /128 via gateway route
2. Send some traffic and RTF_CACHE rt is created
3. Delete the /128 route by ip route del. I suspect the RTF_CACHE route may be
deleted and the route added in (1) stays.
Thanks
^ permalink raw reply
* Re: [PATCH] ARCNET: Add missing error check for devm_kzalloc
From: David Miller @ 2015-02-05 23:53 UTC (permalink / raw)
To: kiran.padwal; +Cc: m.grzeschik, netdev, linux-kernel, kiran.padwal21
In-Reply-To: <1423135897-20448-1-git-send-email-kiran.padwal@smartplayin.com>
From: Kiran Padwal <kiran.padwal@smartplayin.com>
Date: Thu, 5 Feb 2015 17:01:37 +0530
> This patch add a missing check on the return value of devm_kzalloc,
> which would cause a NULL pointer dereference in a OOM situation.
>
> Signed-off-by: Kiran Padwal <kiran.padwal@smartplayin.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] hso: Use static attribute groups for sysfs entry
From: David Miller @ 2015-02-05 23:52 UTC (permalink / raw)
To: tiwai-l3A5Bk7waGM
Cc: j.dumon-x9gZzRpC1QbQT0dZR+AlfA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1423131324-7379-1-git-send-email-tiwai-l3A5Bk7waGM@public.gmane.org>
From: Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>
Date: Thu, 5 Feb 2015 11:15:24 +0100
> Pass the static attribute groups and the driver data via
> tty_port_register_device_attr() instead of manual device_create_file()
> and device_remove_file() calls.
>
> Signed-off-by: Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>
> ---
> v1->v2: rebased to linux-next
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/6 v2 net-next] rhashtable fixes
From: David Miller @ 2015-02-05 23:43 UTC (permalink / raw)
To: tgraf; +Cc: netdev, herbert, ying.xue
In-Reply-To: <cover.1423097592.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Thu, 5 Feb 2015 02:03:30 +0100
> This series fixes all remaining known issues with rhashtable that
> have been reported. In particular the race condition reported by
> Ying Xue.
>
> ---
> Dave/Herbert: I'm posting this now as it fixes real issues. I'm
> fine with taking Herbert's rehash patches instead if they resolve
> all the reported issues as well.
Herbert, please tell me what you'd like me to do.
^ permalink raw reply
* Re: [PATCH net] pktgen: fix UDP checksum computation
From: David Miller @ 2015-02-05 23:42 UTC (permalink / raw)
To: sd; +Cc: netdev, tgraf
In-Reply-To: <1423087730-9201-1-git-send-email-sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Wed, 4 Feb 2015 23:08:50 +0100
> This patch fixes two issues in UDP checksum computation in pktgen.
>
> First, the pseudo-header uses the source and destination IP
> addresses. Currently, the ports are used for IPv4.
>
> Second, the UDP checksum covers both header and data. So we need to
> generate the data earlier (move pktgen_finalize_skb up), and compute
> the checksum for UDP header + data.
>
> Fixes: c26bf4a51308c ("pktgen: Add UDPCSUM flag to support UDP checksums")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 0/3] Fix checkpatch errors in drivers/isdn/isdnloop
From: David Miller @ 2015-02-05 23:42 UTC (permalink / raw)
To: baspeters93; +Cc: isdn, netdev, linux-kernel
In-Reply-To: <1423089181-15850-1-git-send-email-baspeters93@gmail.com>
From: Bas Peters <baspeters93@gmail.com>
Date: Wed, 4 Feb 2015 23:32:58 +0100
> This patchset adresses various checkpatch errors in the abovementioned driver.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next] xfrm6: Fix a offset value for network header in _decode_session6
From: David Miller @ 2015-02-05 23:38 UTC (permalink / raw)
To: tazaki; +Cc: netdev, steffen.klassert, herbert
In-Reply-To: <m2d25phhox.wl@sfc.wide.ad.jp>
From: Hajime Tazaki <tazaki@sfc.wide.ad.jp>
Date: Wed, 04 Feb 2015 23:31:10 +0900
> When a network-layer header has multiple IPv6 extension headers, then offset
> for mobility header goes wrong. This regression breaks an xfrm policy lookup
> for a particular receive packet. Binding update packets of Mobile IPv6
> are all discarded without this fix.
>
> Fixes: de3b7a06dfe1 ("xfrm6: Fix transport header offset in _decode_session6.")
> Signed-off-by: Hajime Tazaki <tazaki@sfc.wide.ad.jp>
Steffen, please review and/or integrate into your tree.
Thanks.
^ permalink raw reply
* Re: [PATCH net v4] net: ipv6: allow explicitly choosing optimistic addresses
From: David Miller @ 2015-02-05 23:37 UTC (permalink / raw)
To: ek; +Cc: netdev, lorenzo, hannes
In-Reply-To: <1423047683-16267-1-git-send-email-ek@google.com>
From: Erik Kline <ek@google.com>
Date: Wed, 4 Feb 2015 20:01:23 +0900
> RFC 4429 ("Optimistic DAD") states that optimistic addresses
> should be treated as deprecated addresses. From section 2.1:
>
> Unless noted otherwise, components of the IPv6 protocol stack
> should treat addresses in the Optimistic state equivalently to
> those in the Deprecated state, indicating that the address is
> available for use but should not be used if another suitable
> address is available.
>
> Optimistic addresses are indeed avoided when other addresses are
> available (i.e. at source address selection time), but they have
> not heretofore been available for things like explicit bind() and
> sendmsg() with struct in6_pktinfo, etc.
>
> This change makes optimistic addresses treated more like
> deprecated addresses than tentative ones.
>
> Signed-off-by: Erik Kline <ek@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC] Possible data stall with RPS and CPU hotplug
From: subashab @ 2015-02-05 23:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, therbert
In-Reply-To: <1423012751.907.49.camel@edumazet-glaptop2.roam.corp.google.com>
Thanks for the suggestion. It appears to be an oversight on my part that
the device where the crash was reported did not have commit
ac64da0b83d82abe62f78b3d0e21cca31aea24fa ("net: rps: fix cpu unplug").
> On Wed, 2015-02-04 at 00:52 +0000, subashab@codeaurora.org wrote:
>> We have an RPS configuration to process packets on Core3 while hardware
>> interrupts arrive on Core0. We see an occasional stall when Core3 is hot
>> plugged out and comes back up at a later point in time. At the time of
>> this stall, we notice that the maximum backlog queue size of 1000 is
>> reached and subsequent packets are dropped, NAPI is scheduled on Core3,
>> but softIRQ NET_RX is not raised on Core3.
>>
>> This leads me to think that possibly the Core3 went offline just before
>> hitting this conditional cpu_online() check in
>> net_rps_action_and_irq_enable(), so the IPI was not delivered to Core3.
>>
>> /* Send pending IPI's to kick RPS processing on remote cpus. */
>> while (remsd) {
>> struct softnet_data *next = remsd->rps_ipi_next;
>> if (cpu_online(remsd->cpu))
>> __smp_call_function_single(remsd->cpu,
>> &remsd->csd, 0);
>> remsd = next;
>> }
>>
>> Later when the Core3 comes back online packets start getting enqueued to
>> Core3 but IPI's are not delivered because NAPI_STATE_SCHED is never
>> cleared on sofnet_data for Core3.
>>
>> enqueue_to_backlog()
>>
>> /* Schedule NAPI for backlog device
>> * We can use non atomic operation since we own the queue lock
>> */
>> if (!__test_and_set_bit(NAPI_STATE_SCHED, &sd->backlog.state)) {
>> if (!rps_ipi_queued(sd))
>> ____napi_schedule(sd, &sd->backlog);
>> }
>> goto enqueue;
>> }
>>
>> Is this analysis correct and does the following patch makes sense?
>>
>> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
>> ---
>> net/core/dev.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 171420e..57663c9 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -7101,6 +7101,7 @@ static int dev_cpu_callback(struct notifier_block
>> *nfb,
>> input_queue_head_incr(oldsd);
>> }
>>
>> + clear_bit(NAPI_STATE_SCHED, oldsd->backlog.state);
>> return NOTIFY_OK;
>> }
>>
>
> Really, this should not be needed after commit
> ac64da0b83d82abe62f78b3d0e21cca31aea24fa
> ("net: rps: fix cpu unplug")
>
> If NAPI_STATE_SCHED was set on oldsd->backlog.state, then we must have
> found the napi in oldsd->poll_list
>
> So we should have hit line 7125 :
>
> if (napi->poll == process_backlog)
> 7125: napi->state = 0;
> else
> ____napi_schedule(sd, napi);
>
> So if you find this bit set, there is another bug ?
>
>
> But it looks like we do not use proper netif_rx() variant in this path.
>
> We run from process context, so we need (at least) following patch :
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index
> 1d564d68e31a5f361fc233ae90a3a19e82915664..947a291223f5437bc004f7fcbb3a938ecba6ced0
> 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -7132,11 +7132,11 @@ static int dev_cpu_callback(struct notifier_block
> *nfb,
>
> /* Process offline CPU's input_pkt_queue */
> while ((skb = __skb_dequeue(&oldsd->process_queue))) {
> - netif_rx_internal(skb);
> + netif_rx_ni(skb);
> input_queue_head_incr(oldsd);
> }
> while ((skb = skb_dequeue(&oldsd->input_pkt_queue))) {
> - netif_rx_internal(skb);
> + netif_rx_ni(skb);
> input_queue_head_incr(oldsd);
> }
>
>
>
> --
> 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: Invalid timestamp? causing tight ack loop (hundreds of thousands of packets / sec)
From: Avery Fay @ 2015-02-05 23:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Neal Cardwell
In-Reply-To: <1423052431.907.112.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, Feb 4, 2015 at 4:20 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Nice, something is really broken on this peer (not a linux one for
> sure), or some really buggy middlebox.
>
> The strange [P.] frame with no payload has a wrong sequence number
> anyway, so we send back a duplicate ack.
Thanks for this analysis. I've tried to reach out to the gatech NOC to
identify the device, but I haven't been able to get a response from
anyone (except general support, but they don't want to put me in touch
with someone who can help).
>
> Neal patches definitely would solve this issue.
>
>
Are these available anywhere? Or could they be made available? This
seems like a much better solution than disabling timestamps.
Avery
^ permalink raw reply
* RE: [net-next 03/16] ixgbe: cleanup sparse errors in new ixgbe_x550.c file
From: Skidmore, Donald C @ 2015-02-05 23:19 UTC (permalink / raw)
To: David Miller, David.Laight@ACULAB.COM
Cc: Kirsher, Jeffrey T, netdev@vger.kernel.org, nhorman@redhat.com,
sassmann@redhat.com, jogreene@redhat.com
In-Reply-To: <20150205.144007.1425782923410995381.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Thursday, February 05, 2015 2:40 PM
> To: David.Laight@ACULAB.COM
> Cc: Kirsher, Jeffrey T; Skidmore, Donald C; netdev@vger.kernel.org;
> nhorman@redhat.com; sassmann@redhat.com; jogreene@redhat.com
> Subject: Re: [net-next 03/16] ixgbe: cleanup sparse errors in new
> ixgbe_x550.c file
>
> From: David Laight <David.Laight@ACULAB.COM>
> Date: Thu, 5 Feb 2015 09:48:24 +0000
>
> > From: Jeff Kirsher
> >> This patch cleans up prototypes that should have been defined as
> >> static.
> >>
> >> Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com>
> >> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
> >> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> >> ---
> >> drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 4 +-
> >> drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 65
> >> ++++++++++++++-------------
> >> 2 files changed, 37 insertions(+), 32 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
> >> b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
> >> index d101b25..1f301ec 100644
> >> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
> >> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
> >> @@ -2451,8 +2451,8 @@ struct ixgbe_hic_read_shadow_ram {
> >>
> >> struct ixgbe_hic_write_shadow_ram {
> >> union ixgbe_hic_hdr2 hdr;
> >> - u32 address;
> >> - u16 length;
> >> + __be32 address;
> >> + __be16 length;
> >> u16 pad2;
> >> u16 data;
> >> u16 pad3;
> >
> > Not related to commit message
>
> Agreed, fix this up.
I'll get a cleaned up patch to Jeff.
Thanks,
-Don Skidmore <donald.c.skidmore@intel.com>
^ permalink raw reply
* Re: [RFC PATCH 00/29] net: VRF support
From: roopa @ 2015-02-05 23:12 UTC (permalink / raw)
To: David Ahern
Cc: netdev, ebiederm, Dinesh Dutt, Vipin Kumar, Nicolas Dichtel,
hannes
In-Reply-To: <1423100070-31848-1-git-send-email-dsahern@gmail.com>
On 2/4/15, 5:34 PM, David Ahern wrote:
> Kernel patches are also available here:
> https://github.com/dsahern/linux.git vrf-3.19
>
> iproute2 patches are also available here:
> https://github.com/dsahern/iproute2 vrf-3.19
>
>
> Background
> ----------
> The concept of VRFs (Virtual Routing and Forwarding) has been around for over
> 15 years. Support for VRFs in the Linux kernel has been an often requested
> feature for almost as long. For a while support was available via an out of
> tree patch [1]. Since network namespaces came along, the response to queries
> about VRF support for Linux was 'use namespaces'. But as mentioned previously
> [2] network namespaces are not a good match for VRFs. Of the list of problems
> noted the big one is that namespaces do not scale efficiently to the number
> of VRFs supported by networking gear (> 1000 VRFs). Networking vendors that
> want to use Linux as the OS have to carry custom solutions to this problem --
> be it userspace networking stacks, extensive kernel patches (to add VRF
> support or bend the implementation of namespaces), and/or patches to many
> open source components. The recent addition of switchdev support in the
> kernel suggests that people expect the use of Linux as a switch networking
> OS to increase. Hopefully the time is right to re-open the discussion on a
> salable VRF implementation for the Linux kernel.
>
> The intent of this RFC is to get feedback on the overall idea - namely VRFs
> as integer id and the nesting of VRFs within a namespace. This set includes
> changes only to core IPv4 code which shows the concept; changes to the rest
> of the network stack are fairly repetitive.
>
> This patch set has a number of similarities to the original VRF patch - most
> notably VRF ids as an integer index and plumbing through iproute2 and
> netlink. But this set is really a complete re-implementation of the feature,
> integrating VRF within a namespace and leveraging existing support for
> network namespaces.
>
> Design
> ------
> Namespaces provide excellent separation of the networking stack from the
> netdevices and up. The intent of VRFs is to provide an additional,
> logical separation at the L3 layer within a namespace.
>
> +----------------------------------------------------------+
> | Namespace foo |
> | +---------------+ |
> | +------+ | L3/L4 service | |
> | | lldp | | (VRF any) | |
> | +------+ +---------------+ |
> | |
> | +-------------------------+ |
> | | VRF M | |
> | +---------------------+ +-------------------------+ | |
> | | VRF 1 (default) | | VRF N | | |
> | | +---------------+ | | +---------------+ | | |
> | | | L3/L4 service | | | | L3/L4 service | | | |
> | | | (VRF unaware) | | | | (VRF unaware) | | | |
> | | +---------------+ | | +---------------+ | | |
> | | | | | | |
> | |+-----+ +----------+ | | +-----+ +----------+ | | |
> | || FIB | | neighbor | | | | FIB | | neighbor | | | |
> | |+-----+ +----------+ | | +-----+ +----------+ | | |
> | | | | |-+ |
> | | {dev 1} {dev 2} | | {dev 3} {dev 4} {dev 5} | |
> | +---------------------+ +-------------------------+ |
> +----------------------------------------------------------+
>
> This is accomplished by enhancing the current namespace checks to a
> broader network context that is both a namepsace and a VRF id. The VRF
> id is a tag applied to relevant structures, an integer between 1 and 4095
> which allows for 4095 VRFs (could have 0 be the default VRF and then the
> range is 0-4095 = 4096s VRFs). (The limitation is arguably artificial. It
> is based on the genid scheme for versioning networking data which is a
> 32-bit integer. The VRF id is the lower 12 bits of the genid's.)
>
> Netdevices, sk_buffs, sockets, and tasks are all tagged with a VRF id.
> Network lookups (devices, sockets, addresses, routes, neighbors) require a
> match of both network namespace and VRF id (or the special 'vrf any' tag;
> more on that later).
>
>
David,
Wondering if you have thought about some of the the below cases in your
approach to vrfs ?.
- Leaking routes from one vrf to another
- route lookup in one vrf on failure to fallback to the global vrf (This
for example can be done using throw if we used ip rules and route tables
to do the same).
- A route in one vrf pointing to a nexthop in another vrf
We have been playing with ip rules to implement vrfs. And the blocker
today is that we cannot bind a socket to a vrf (routing tables in this
case).
Thanks,
Roopa
^ permalink raw reply
* [PATCH net] net: use netif_rx_ni() from process context
From: Eric Dumazet @ 2015-02-05 22:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Hotpluging a cpu might be rare, yet we have to use proper
handlers when taking over packets found in backlog queues.
dev_cpu_callback() runs from process context, thus we should
call netif_rx_ni() to properly invoke softirq handler.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
I never saw real operational issues, but I suspect this patch cannot
hurt.
net/core/dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 7fe82929f509..6c1556aeec29 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -7064,11 +7064,11 @@ static int dev_cpu_callback(struct notifier_block *nfb,
/* Process offline CPU's input_pkt_queue */
while ((skb = __skb_dequeue(&oldsd->process_queue))) {
- netif_rx_internal(skb);
+ netif_rx_ni(skb);
input_queue_head_incr(oldsd);
}
while ((skb = skb_dequeue(&oldsd->input_pkt_queue))) {
- netif_rx_internal(skb);
+ netif_rx_ni(skb);
input_queue_head_incr(oldsd);
}
^ permalink raw reply related
* Re: Ethernet: how to disable gigabit support
From: Florian Fainelli @ 2015-02-05 22:44 UTC (permalink / raw)
To: Pavel Machek, kernel list, netdev
In-Reply-To: <20150205202527.GA7917@amd>
On 05/02/15 12:25, Pavel Machek wrote:
> Hi!
>
> This happened on more than one project: there's gigabit-capable chip,
> but the connector is not designed for gigabit speed.
>
> I'd like to have speed autonegotiation, but not offer gigabit (as it
> will not work).
>
> Is there way to do that without hacking the kernel? Should mii-tool do
> that?
Since you use the PHY library, you should be able to do something like
this in your PHY driver prior to starting the PHY state machine:
phydev->supported &= PHY_BASIC_FEATURES (effectively masking Gigabit
capability)
See drivers/net/ethernet/broadcom/genet/bcmmii.c for instance where this
is done based on the type of interface (RevMII, MII) we are connected to.
>
> Thanks,
> Pavel
>
> root@ib8315:~# mii-tool.net-tools -A 100baseTx,10baseT eth1
> restarting autonegotiation...
> root@ib8315:~# [32432.443883] libphy: mdio@e0024520:01 - Link is Down
>
> root@ib8315:~# [32435.447863] libphy: mdio@e0024520:01 - Link is Up - 1000/Full
>
> root@ib8315:~# mii-tool.net-tools -v eth1
> eth1: negotiated 1000baseT-FD flow-control, link ok
> product info: vendor 00:01:c1, model 3 rev 1
> basic mode: autonegotiation enabled
> basic status: autonegotiation complete, link ok
> capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
> advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
> link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD flow-control
> root@ib8315:~# mii-tool.net-tools -V
> $Id: mii-tool.c,v 1.9 2006/09/27 20:59:18 ecki Exp $
> (Author: David Hinds based on Donald Becker's mii-diag)
> net-tools 1.60
> root@ib8315:~#
>
>
--
Florian
^ 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