* Re: [PATCH net v3] ipv6: mld: fix add_grhead skb_over_panic for devs with large MTUs
From: Daniel Borkmann @ 2014-11-05 17:59 UTC (permalink / raw)
To: Eric Dumazet
Cc: Hannes Frederic Sowa, davem, lw1a2.jing, fw, netdev, Eric Dumazet,
David L Stevens
In-Reply-To: <1415206106.13896.8.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/05/2014 05:48 PM, Eric Dumazet wrote:
> On Wed, 2014-11-05 at 17:38 +0100, Hannes Frederic Sowa wrote:
...
>> I would still vote for this version, but see the problem with the noise
>> caused by newline updates. Eric, would you mind a new version with only
>> the essential parts changed and keeping this calculation so we don't
>> need to change it twice for net and for net-next?
>
> I will be happy to review a v4 ;)
No problem, I'll respin. ;)
Thanks,
Daniel
^ permalink raw reply
* Re: Kernel Oops in __inet_twsk_kill()
From: Cong Wang @ 2014-11-05 18:00 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: charley.chu, netdev
In-Reply-To: <545A49B4.7090107@iogearbox.net>
On Wed, Nov 5, 2014 at 8:00 AM, Daniel Borkmann <borkmann@iogearbox.net> wrote:
> [ moving to netdev ]
>
> -------- Original Message --------
> Subject: Kernel Oops in __inet_twsk_kill()
> Date: Tue, 4 Nov 2014 23:47:18 +0000
> From: Charley (Hao Chuan) Chu <charley.chu@broadcom.com>
> To: linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
>
> We have situation on our system. It brings the network interface up and down
> every
> a few seconds. Eventually, it brings down the system - the kernel crashed
> due to BUG
> on in __inet_twsk_kill(). The debug message show following call flow.
>
> 1) time-wait socket is created by tcp_time_wait() when the socket gets into
> "TIME_WAIT" state.
> inet_twsk_alloc() - refcnt= 0
> inet_twsk_hashdance() - refcnt = 3
> inet_twsk_schedule() - refcnt = 4
> inet_twsk_put() - refcnt = 3
> 2) tcp_v4_timewait_ack() is called when sync is received
> inet_twsk_put() - refcnt= 2 <== where we thing the
> problem is
> occasionally, second sync is received, so the inet_twsk_put is called
> twice - refcnt = 1
> 3) twdr_do_twkill_work() is called when timed out
> call __inet_twsk_kill - BUG_ON!!! as refcnt=2 (supposed to be 3).
> call inet_twsk_put()
>
> In a normal case, the callflow only has step 1 and step 3. Our
> understanding is
> the time-wait socket has three references - ehash, bhash and timer death
> row. In
> step 2, none of them are touched. Can anyone here explain to us why the
> inet_twsk_put()
> is called in tcp_v4_timewait_ack()?
>
It has been there for a rather long time, but this doesn't mean it is
correct. Its caller calls inet_twsk_put() on error path, so smells wrong
to call it on non-error path. But I don't look into this.
^ permalink raw reply
* Re: [PATCH net 0/5] Implement ndo_gso_check() for vxlan nics
From: Tom Herbert @ 2014-11-05 18:00 UTC (permalink / raw)
To: Joe Stringer
Cc: Or Gerlitz, Linux Netdev List, sathya.perla, Jeff Kirsher,
linux.nics, Amir Vadai, shahed.shaikh, dept-gelinuxnicdev,
Linux Kernel
In-Reply-To: <CANr6G5xtNYenhd8KDWx+kRcnSZ0fahUdAL+6Wcz=5_dNvrQR6Q@mail.gmail.com>
On Wed, Nov 5, 2014 at 9:50 AM, Joe Stringer <joestringer@nicira.com> wrote:
>
> On 5 November 2014 04:38, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>>
>> On Tue, Nov 4, 2014 at 11:56 PM, Joe Stringer <joestringer@nicira.com> wrote:
>> > Most NICs that report NETIF_F_GSO_UDP_TUNNEL support VXLAN, and not other
>> > UDP-based encapsulation protocols where the format and size of the header may
>> > differ. This patch series implements ndo_gso_check() for these NICs,
>> > restricting the GSO handling to something that looks and smells like VXLAN.
>> >
>> > Implementation shamelessly stolen from Tom Herbert (with minor fixups):
>> > http://thread.gmane.org/gmane.linux.network/332428/focus=333111
>>
>>
>> Hi Joe,
>>
>> 1st, thanks for picking this task...2nd, for drivers that currently
>> support only pure VXLAN, I don't see the point
>> to replicate the helper suggested by Tom (good catch on the size check
>> to be 16 and not 12) four times and who know how more in the future.
>> Let's just have one generic helper and make the mlx4/be/fm10k/benet
>> drivers to have it as their ndo, OK?
>
>
> Thanks for taking a look.
>
> I had debated whether to do this or not as the actual support on each NIC may differ, and each implementation may morph over time to match these capabilities better. Obviously the vendors will know better than me on this, so I'm posing this series to prod them for more information. At this point I've had just one maintainer come back and confirm that this helper is a good fit for their hardware, so I'd like to confirm that multiple drivers will use a ndo_gso_check_vxlan_helper() function before I go and create it.
Thanks for implementing this fix!
Personally, I would rather not have the helper. This is already a
small number of drivers, and each driver owner should consider what
limitations are of their device and try to enable to allow the maximum
number of use cases possible. I'm also hoping that new devices will
implement the more generic mechanism so that VXLAN is just one
supported protocol.
^ permalink raw reply
* Can ndo_select_queue save data in skb->cb?
From: James Yonan @ 2014-11-05 17:57 UTC (permalink / raw)
To: netdev
Is it permissible for a net driver's ndo_select_queue method to save
data in skb->cb for later use in ndo_start_xmit?
Also, is it necessary for users of skb->cb to zero out their private
data after use to prevent it from being misinterpreted by other layers?
I noticed some commits in the log (such as 462fb2) are zeroing out the
skb->cb area for this reason.
Thanks,
James
^ permalink raw reply
* [PATCH v2 iproute2 0/5] iproute2: Add FOU and GUE configuration in ip
From: Tom Herbert @ 2014-11-05 18:06 UTC (permalink / raw)
To: stephen, davem, netdev
This patch set adds support in iproute2 to configure FOU and GUE ports
for receive, and using FOU or GUE with ip tunnels (IPIP, GRE, sit) on
transmit.
A new ip subcommand "fou" has been added to configure FOU/GUE ports.
For example:
ip fou add port 5555 gue
ip fou add port 9999 ipproto 4
The first command creates a GUE port, the second creates a direct FOU
port for IPIP (receive payload is a assumed to be an IP packet).
fou.8 and gue.8 man pages were added to describe this command.
To configure an IP tunnel to use FOU or GUE encap parameters have
been added. For example:
ip link add name tun1 type ipip remote 192.168.1.1 local 192.168.1.2 \
ttl 225 encap gue encap-sport auto encap-dport 7777 encap-csum
ip link add name tun2 type gre remote 192.168.1.1 local 192.168.1.2 \
ttl 225 encap fou encap-sport auto encap-dport 8888 encap-csum
The first command configures an IPIP tunnel to use GUE on transmit. The
peer might be configured to receive GUE packets with the
"ip fou add port 7777 gue" command.
The second configures a GRE tunnel to use FOU encapsulation. The
peer might be configured to receive these packets with the
"ip fou add port 8888 ipproto 47" command.
v2:
- Add man pages fou.8 and gue.8
- Add ntohs for print ports in configuration
- Add support for remote checksum offload
Tom Herbert (5):
ip fou: Support to configure foo-over-udp RX
ip link ipip: Add support to configure FOU and GUE
ip link gre: Add support to configure FOU and GUE
ip link: Add support for remote checksum offload
iproute2: Man pages for fou and gue
include/linux/fou.h | 41 ++++++++++++
include/linux/if_tunnel.h | 1 +
ip/Makefile | 2 +-
ip/ip.c | 3 +-
ip/ip_common.h | 1 +
ip/ipfou.c | 159 ++++++++++++++++++++++++++++++++++++++++++++++
ip/link_gre.c | 98 ++++++++++++++++++++++++++++
ip/link_iptnl.c | 98 ++++++++++++++++++++++++++++
man/man8/ip-fou.8 | 76 ++++++++++++++++++++++
man/man8/ip-gue.8 | 1 +
10 files changed, 478 insertions(+), 2 deletions(-)
create mode 100644 include/linux/fou.h
create mode 100644 ip/ipfou.c
create mode 100644 man/man8/ip-fou.8
create mode 100644 man/man8/ip-gue.8
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply
* [PATCH v2 iproute2 1/5] ip fou: Support to configure foo-over-udp RX
From: Tom Herbert @ 2014-11-05 18:06 UTC (permalink / raw)
To: stephen, davem, netdev
In-Reply-To: <1415210788-8058-1-git-send-email-therbert@google.com>
Added 'ip fou...' commands to enable/disable UDP ports for doing
foo-over-udp and Generic UDP Encapsulation variant. Arguments are port
number to bind to and IP protocol to map to port (for direct FOU).
Examples:
ip fou add port 7777 gue
ip fou add port 8888 ipproto 4
The first command creates a GUE port, the second creates a direct FOU
port for IPIP (receive payload is a assumed to be an IPv4 packet).
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/linux/fou.h | 41 ++++++++++++++
ip/Makefile | 2 +-
ip/ip.c | 3 +-
ip/ip_common.h | 1 +
ip/ipfou.c | 159 ++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 204 insertions(+), 2 deletions(-)
create mode 100644 include/linux/fou.h
create mode 100644 ip/ipfou.c
diff --git a/include/linux/fou.h b/include/linux/fou.h
new file mode 100644
index 0000000..e1724ff
--- /dev/null
+++ b/include/linux/fou.h
@@ -0,0 +1,41 @@
+/* fou.h - FOU Interface */
+
+#ifndef _LINUX_FOU_H
+#define _LINUX_FOU_H
+
+#include <linux/types.h>
+
+/* NETLINK_GENERIC related info
+ */
+#define FOU_GENL_NAME "fou"
+#define FOU_GENL_VERSION 0x1
+
+enum {
+ FOU_ATTR_UNSPEC,
+ FOU_ATTR_PORT, /* u16 */
+ FOU_ATTR_AF, /* u8 */
+ FOU_ATTR_IPPROTO, /* u8 */
+ FOU_ATTR_TYPE, /* u8 */
+
+ __FOU_ATTR_MAX,
+};
+
+#define FOU_ATTR_MAX (__FOU_ATTR_MAX - 1)
+
+enum {
+ FOU_CMD_UNSPEC,
+ FOU_CMD_ADD,
+ FOU_CMD_DEL,
+
+ __FOU_CMD_MAX,
+};
+
+enum {
+ FOU_ENCAP_UNSPEC,
+ FOU_ENCAP_DIRECT,
+ FOU_ENCAP_GUE,
+};
+
+#define FOU_CMD_MAX (__FOU_CMD_MAX - 1)
+
+#endif /* _LINUX_FOU_H */
diff --git a/ip/Makefile b/ip/Makefile
index 5405ee7..1f50848 100644
--- a/ip/Makefile
+++ b/ip/Makefile
@@ -6,7 +6,7 @@ IPOBJ=ip.o ipaddress.o ipaddrlabel.o iproute.o iprule.o ipnetns.o \
iplink_macvlan.o iplink_macvtap.o ipl2tp.o link_vti.o link_vti6.o \
iplink_vxlan.o tcp_metrics.o iplink_ipoib.o ipnetconf.o link_ip6tnl.o \
link_iptnl.o link_gre6.o iplink_bond.o iplink_bond_slave.o iplink_hsr.o \
- iplink_bridge.o iplink_bridge_slave.o
+ iplink_bridge.o iplink_bridge_slave.o ipfou.o
RTMONOBJ=rtmon.o
diff --git a/ip/ip.c b/ip/ip.c
index e4b201f..5f759d5 100644
--- a/ip/ip.c
+++ b/ip/ip.c
@@ -47,7 +47,7 @@ static void usage(void)
" ip [ -force ] -batch filename\n"
"where OBJECT := { link | addr | addrlabel | route | rule | neigh | ntable |\n"
" tunnel | tuntap | maddr | mroute | mrule | monitor | xfrm |\n"
-" netns | l2tp | tcp_metrics | token | netconf }\n"
+" netns | l2tp | fou | tcp_metrics | token | netconf }\n"
" OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |\n"
" -h[uman-readable] | -iec |\n"
" -f[amily] { inet | inet6 | ipx | dnet | bridge | link } |\n"
@@ -79,6 +79,7 @@ static const struct cmd {
{ "ntbl", do_ipntable },
{ "link", do_iplink },
{ "l2tp", do_ipl2tp },
+ { "fou", do_ipfou },
{ "tunnel", do_iptunnel },
{ "tunl", do_iptunnel },
{ "tuntap", do_iptuntap },
diff --git a/ip/ip_common.h b/ip/ip_common.h
index 8351463..095c92d 100644
--- a/ip/ip_common.h
+++ b/ip/ip_common.h
@@ -48,6 +48,7 @@ extern int do_multirule(int argc, char **argv);
extern int do_netns(int argc, char **argv);
extern int do_xfrm(int argc, char **argv);
extern int do_ipl2tp(int argc, char **argv);
+extern int do_ipfou(int argc, char **argv);
extern int do_tcp_metrics(int argc, char **argv);
extern int do_ipnetconf(int argc, char **argv);
extern int do_iptoken(int argc, char **argv);
diff --git a/ip/ipfou.c b/ip/ipfou.c
new file mode 100644
index 0000000..2676045
--- /dev/null
+++ b/ip/ipfou.c
@@ -0,0 +1,159 @@
+/*
+ * ipfou.c FOU (foo over UDP) support
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Tom Herbert <therbert@google.com>
+ */
+
+#include <netdb.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <net/if.h>
+#include <linux/fou.h>
+#include <linux/genetlink.h>
+#include <linux/ip.h>
+#include <arpa/inet.h>
+
+#include "libgenl.h"
+#include "utils.h"
+#include "ip_common.h"
+
+static void usage(void)
+{
+ fprintf(stderr, "Usage: ip fou add port PORT { ipproto PROTO | gue }\n");
+ fprintf(stderr, " ip fou del port PORT\n");
+ fprintf(stderr, "\n");
+ fprintf(stderr, "Where: PROTO { ipproto-name | 1..255 }\n");
+ fprintf(stderr, " PORT { 1..65535 }\n");
+
+ exit(-1);
+}
+
+/* netlink socket */
+static struct rtnl_handle genl_rth = { .fd = -1 };
+static int genl_family = -1;
+
+#define FOU_REQUEST(_req, _bufsiz, _cmd, _flags) \
+ GENL_REQUEST(_req, _bufsiz, genl_family, 0, \
+ FOU_GENL_VERSION, _cmd, _flags)
+
+static int fou_parse_opt(int argc, char **argv, struct nlmsghdr *n,
+ bool adding)
+{
+ __u16 port;
+ int port_set = 0;
+ __u8 ipproto, type;
+ bool gue_set = false;
+ int ipproto_set = 0;
+
+ while (argc > 0) {
+ if (!matches(*argv, "port")) {
+ NEXT_ARG();
+
+ if (get_u16(&port, *argv, 0) || port == 0)
+ invarg("invalid port", *argv);
+ port = htons(port);
+ port_set = 1;
+ } else if (!matches(*argv, "ipproto")) {
+ struct protoent *servptr;
+
+ NEXT_ARG();
+
+ servptr = getprotobyname(*argv);
+ if (servptr)
+ ipproto = servptr->p_proto;
+ else if (get_u8(&ipproto, *argv, 0) || ipproto == 0)
+ invarg("invalid ipproto", *argv);
+ ipproto_set = 1;
+ } else if (!matches(*argv, "gue")) {
+ gue_set = true;
+ } else {
+ fprintf(stderr, "fou: unknown command \"%s\"?\n", *argv);
+ usage();
+ return -1;
+ }
+ argc--, argv++;
+ }
+
+ if (!port_set) {
+ fprintf(stderr, "fou: missing port\n");
+ return -1;
+ }
+
+ if (!ipproto_set && !gue_set && adding) {
+ fprintf(stderr, "fou: must set ipproto or gue\n");
+ return -1;
+ }
+
+ if (ipproto_set && gue_set) {
+ fprintf(stderr, "fou: cannot set ipproto and gue\n");
+ return -1;
+ }
+
+ type = gue_set ? FOU_ENCAP_GUE : FOU_ENCAP_DIRECT;
+
+ addattr16(n, 1024, FOU_ATTR_PORT, port);
+ addattr8(n, 1024, FOU_ATTR_TYPE, type);
+
+ if (ipproto_set)
+ addattr8(n, 1024, FOU_ATTR_IPPROTO, ipproto);
+
+ return 0;
+}
+
+static int do_add(int argc, char **argv)
+{
+ FOU_REQUEST(req, 1024, FOU_CMD_ADD, NLM_F_REQUEST);
+
+ fou_parse_opt(argc, argv, &req.n, true);
+
+ if (rtnl_talk(&genl_rth, &req.n, 0, 0, NULL) < 0)
+ return -2;
+
+ return 0;
+}
+
+static int do_del(int argc, char **argv)
+{
+ FOU_REQUEST(req, 1024, FOU_CMD_DEL, NLM_F_REQUEST);
+
+ fou_parse_opt(argc, argv, &req.n, false);
+
+ if (rtnl_talk(&genl_rth, &req.n, 0, 0, NULL) < 0)
+ return -2;
+
+ return 0;
+}
+
+int do_ipfou(int argc, char **argv)
+{
+ if (genl_family < 0) {
+ if (rtnl_open_byproto(&genl_rth, 0, NETLINK_GENERIC) < 0) {
+ fprintf(stderr, "Cannot open generic netlink socket\n");
+ exit(1);
+ }
+
+ genl_family = genl_resolve_family(&genl_rth, FOU_GENL_NAME);
+ if (genl_family < 0)
+ exit(1);
+ }
+
+ if (argc < 1)
+ usage();
+
+ if (matches(*argv, "add") == 0)
+ return do_add(argc-1, argv+1);
+ if (matches(*argv, "delete") == 0)
+ return do_del(argc-1, argv+1);
+ if (matches(*argv, "help") == 0)
+ usage();
+
+ fprintf(stderr, "Command \"%s\" is unknown, try \"ip fou help\".\n", *argv);
+ exit(-1);
+}
+
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH v2 iproute2 2/5] ip link ipip: Add support to configure FOU and GUE
From: Tom Herbert @ 2014-11-05 18:06 UTC (permalink / raw)
To: stephen, davem, netdev
In-Reply-To: <1415210788-8058-1-git-send-email-therbert@google.com>
This patch adds support to configure foo-over-udp (FOU) and Generic
UDP Encapsulation for IPIP and sit tunnels. This configuration allows
selection of FOU or GUE for the tunnel, specification of the source and
destination ports for UDP tunnel, and enabling TX checksum. This
configuration only affects the transmit side of a tunnel.
Example:
ip link add name tun1 type ipip remote 192.168.1.1 local 192.168.1.2 \
ttl 225 encap gue encap-sport auto encap-dport 9999 encap-csum
This would create an IPIP tunnel in GUE encapsulation where the source
port is automatically selected (based on hash of inner packet) and
checksums in the encapsulating UDP header are enabled.
Signed-off-by: Tom Herbert <therbert@google.com>
---
ip/link_iptnl.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 89 insertions(+)
diff --git a/ip/link_iptnl.c b/ip/link_iptnl.c
index ea13ce9..9487117 100644
--- a/ip/link_iptnl.c
+++ b/ip/link_iptnl.c
@@ -29,6 +29,9 @@ static void print_usage(FILE *f, int sit)
fprintf(f, " type { ipip | sit } [ remote ADDR ] [ local ADDR ]\n");
fprintf(f, " [ ttl TTL ] [ tos TOS ] [ [no]pmtudisc ] [ dev PHYS_DEV ]\n");
fprintf(f, " [ 6rd-prefix ADDR ] [ 6rd-relay_prefix ADDR ] [ 6rd-reset ]\n");
+ fprintf(f, " [ noencap ] [ encap { fou | gue | none } ]\n");
+ fprintf(f, " [ encap-sport PORT ] [ encap-dport PORT ]\n");
+ fprintf(f, " [ [no]encap-csum ] [ [no]encap-csum6 ]\n");
if (sit) {
fprintf(f, " [ mode { ip6ip | ipip | any } ]\n");
fprintf(f, " [ isatap ]\n");
@@ -72,6 +75,10 @@ static int iptunnel_parse_opt(struct link_util *lu, int argc, char **argv,
__u16 ip6rdprefixlen = 0;
__u32 ip6rdrelayprefix = 0;
__u16 ip6rdrelayprefixlen = 0;
+ __u16 encaptype = 0;
+ __u16 encapflags = 0;
+ __u16 encapsport = 0;
+ __u16 encapdport = 0;
memset(&ip6rdprefix, 0, sizeof(ip6rdprefix));
@@ -134,6 +141,14 @@ get_failed:
if (iptuninfo[IFLA_IPTUN_PROTO])
proto = rta_getattr_u8(iptuninfo[IFLA_IPTUN_PROTO]);
+ if (iptuninfo[IFLA_IPTUN_ENCAP_TYPE])
+ encaptype = rta_getattr_u16(iptuninfo[IFLA_IPTUN_ENCAP_TYPE]);
+ if (iptuninfo[IFLA_IPTUN_ENCAP_FLAGS])
+ encapflags = rta_getattr_u16(iptuninfo[IFLA_IPTUN_ENCAP_FLAGS]);
+ if (iptuninfo[IFLA_IPTUN_ENCAP_SPORT])
+ encapsport = rta_getattr_u16(iptuninfo[IFLA_IPTUN_ENCAP_SPORT]);
+ if (iptuninfo[IFLA_IPTUN_ENCAP_DPORT])
+ encapdport = rta_getattr_u16(iptuninfo[IFLA_IPTUN_ENCAP_DPORT]);
if (iptuninfo[IFLA_IPTUN_6RD_PREFIX])
memcpy(&ip6rdprefix,
RTA_DATA(iptuninfo[IFLA_IPTUN_6RD_PREFIX]),
@@ -211,6 +226,36 @@ get_failed:
proto = 0;
else
invarg("Cannot guess tunnel mode.", *argv);
+ } else if (strcmp(*argv, "noencap") == 0) {
+ encaptype = TUNNEL_ENCAP_NONE;
+ } else if (strcmp(*argv, "encap") == 0) {
+ NEXT_ARG();
+ if (strcmp(*argv, "fou") == 0)
+ encaptype = TUNNEL_ENCAP_FOU;
+ else if (strcmp(*argv, "gue") == 0)
+ encaptype = TUNNEL_ENCAP_GUE;
+ else if (strcmp(*argv, "none") == 0)
+ encaptype = TUNNEL_ENCAP_NONE;
+ else
+ invarg("Invalid encap type.", *argv);
+ } else if (strcmp(*argv, "encap-sport") == 0) {
+ NEXT_ARG();
+ if (strcmp(*argv, "auto") == 0)
+ encapsport = 0;
+ else if (get_u16(&encapsport, *argv, 0))
+ invarg("Invalid source port.", *argv);
+ } else if (strcmp(*argv, "encap-dport") == 0) {
+ NEXT_ARG();
+ if (get_u16(&encapdport, *argv, 0))
+ invarg("Invalid destination port.", *argv);
+ } else if (strcmp(*argv, "encap-csum") == 0) {
+ encapflags |= TUNNEL_ENCAP_FLAG_CSUM;
+ } else if (strcmp(*argv, "noencap-csum") == 0) {
+ encapflags &= ~TUNNEL_ENCAP_FLAG_CSUM;
+ } else if (strcmp(*argv, "encap-udp6-csum") == 0) {
+ encapflags |= TUNNEL_ENCAP_FLAG_CSUM6;
+ } else if (strcmp(*argv, "noencap-udp6-csum") == 0) {
+ encapflags &= ~TUNNEL_ENCAP_FLAG_CSUM6;
} else if (strcmp(*argv, "6rd-prefix") == 0) {
inet_prefix prefix;
NEXT_ARG();
@@ -248,6 +293,12 @@ get_failed:
addattr8(n, 1024, IFLA_IPTUN_TTL, ttl);
addattr8(n, 1024, IFLA_IPTUN_TOS, tos);
addattr8(n, 1024, IFLA_IPTUN_PMTUDISC, pmtudisc);
+
+ addattr16(n, 1024, IFLA_IPTUN_ENCAP_TYPE, encaptype);
+ addattr16(n, 1024, IFLA_IPTUN_ENCAP_FLAGS, encapflags);
+ addattr16(n, 1024, IFLA_IPTUN_ENCAP_SPORT, htons(encapsport));
+ addattr16(n, 1024, IFLA_IPTUN_ENCAP_DPORT, htons(encapdport));
+
if (strcmp(lu->id, "sit") == 0) {
addattr16(n, 1024, IFLA_IPTUN_FLAGS, iflags);
addattr8(n, 1024, IFLA_IPTUN_PROTO, proto);
@@ -350,6 +401,44 @@ static void iptunnel_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[
relayprefixlen);
}
}
+
+ if (tb[IFLA_IPTUN_ENCAP_TYPE] &&
+ *(__u16 *)RTA_DATA(tb[IFLA_IPTUN_ENCAP_TYPE]) != TUNNEL_ENCAP_NONE) {
+ __u16 type = rta_getattr_u16(tb[IFLA_IPTUN_ENCAP_TYPE]);
+ __u16 flags = rta_getattr_u16(tb[IFLA_IPTUN_ENCAP_FLAGS]);
+ __u16 sport = rta_getattr_u16(tb[IFLA_IPTUN_ENCAP_SPORT]);
+ __u16 dport = rta_getattr_u16(tb[IFLA_IPTUN_ENCAP_DPORT]);
+
+ fputs("encap ", f);
+ switch (type) {
+ case TUNNEL_ENCAP_FOU:
+ fputs("fou ", f);
+ break;
+ case TUNNEL_ENCAP_GUE:
+ fputs("gue ", f);
+ break;
+ default:
+ fputs("unknown ", f);
+ break;
+ }
+
+ if (sport == 0)
+ fputs("encap-sport auto ", f);
+ else
+ fprintf(f, "encap-sport %u", ntohs(sport));
+
+ fprintf(f, "encap-dport %u ", ntohs(dport));
+
+ if (flags & TUNNEL_ENCAP_FLAG_CSUM)
+ fputs("encap-csum ", f);
+ else
+ fputs("noencap-csum ", f);
+
+ if (flags & TUNNEL_ENCAP_FLAG_CSUM6)
+ fputs("encap-csum6 ", f);
+ else
+ fputs("noencap-csum6 ", f);
+ }
}
static void iptunnel_print_help(struct link_util *lu, int argc, char **argv,
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH v2 iproute2 3/5] ip link gre: Add support to configure FOU and GUE
From: Tom Herbert @ 2014-11-05 18:06 UTC (permalink / raw)
To: stephen, davem, netdev
In-Reply-To: <1415210788-8058-1-git-send-email-therbert@google.com>
This patch adds support to configure foo-over-udp (FOU) and Generic
UDP Encapsulation for GRE tunnels. This configuration allows selection
of FOU or GUE for the tunnel, specification of the source and
destination ports for UDP tunnel, and enabling TX checksum. This
configuration only affects the transmit side of a tunnel.
Example:
ip link add name tun1 type gre remote 192.168.1.1 local 192.168.1.2 \
ttl 225 encap fou encap-sport auto encap-dport 7777 encap-csum
This would create an GRE tunnel in GUE encapsulation where the source
port is automatically selected (based on hash of inner packet) and
checksums in the encapsulating UDP header are enabled.
Signed-off-by: Tom Herbert <therbert@google.com>
---
ip/link_gre.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 89 insertions(+)
diff --git a/ip/link_gre.c b/ip/link_gre.c
index 83653d0..47b64cb 100644
--- a/ip/link_gre.c
+++ b/ip/link_gre.c
@@ -29,6 +29,9 @@ static void print_usage(FILE *f)
fprintf(f, " type { gre | gretap } [ remote ADDR ] [ local ADDR ]\n");
fprintf(f, " [ [i|o]seq ] [ [i|o]key KEY ] [ [i|o]csum ]\n");
fprintf(f, " [ ttl TTL ] [ tos TOS ] [ [no]pmtudisc ] [ dev PHYS_DEV ]\n");
+ fprintf(f, " [ noencap ] [ encap { fou | gue | none } ]\n");
+ fprintf(f, " [ encap-sport PORT ] [ encap-dport PORT ]\n");
+ fprintf(f, " [ [no]encap-csum ] [ [no]encap-csum6 ]\n");
fprintf(f, "\n");
fprintf(f, "Where: NAME := STRING\n");
fprintf(f, " ADDR := { IP_ADDRESS | any }\n");
@@ -67,6 +70,10 @@ static int gre_parse_opt(struct link_util *lu, int argc, char **argv,
__u8 ttl = 0;
__u8 tos = 0;
int len;
+ __u16 encaptype = 0;
+ __u16 encapflags = 0;
+ __u16 encapsport = 0;
+ __u16 encapdport = 0;
if (!(n->nlmsg_flags & NLM_F_CREATE)) {
memset(&req, 0, sizeof(req));
@@ -132,6 +139,15 @@ get_failed:
if (greinfo[IFLA_GRE_LINK])
link = rta_getattr_u8(greinfo[IFLA_GRE_LINK]);
+
+ if (greinfo[IFLA_GRE_ENCAP_TYPE])
+ encaptype = rta_getattr_u16(greinfo[IFLA_GRE_ENCAP_TYPE]);
+ if (greinfo[IFLA_GRE_ENCAP_FLAGS])
+ encapflags = rta_getattr_u16(greinfo[IFLA_GRE_ENCAP_FLAGS]);
+ if (greinfo[IFLA_GRE_ENCAP_SPORT])
+ encapsport = rta_getattr_u16(greinfo[IFLA_GRE_ENCAP_SPORT]);
+ if (greinfo[IFLA_GRE_ENCAP_DPORT])
+ encapdport = rta_getattr_u16(greinfo[IFLA_GRE_ENCAP_DPORT]);
}
while (argc > 0) {
@@ -241,6 +257,36 @@ get_failed:
tos = uval;
} else
tos = 1;
+ } else if (strcmp(*argv, "noencap") == 0) {
+ encaptype = TUNNEL_ENCAP_NONE;
+ } else if (strcmp(*argv, "encap") == 0) {
+ NEXT_ARG();
+ if (strcmp(*argv, "fou") == 0)
+ encaptype = TUNNEL_ENCAP_FOU;
+ else if (strcmp(*argv, "gue") == 0)
+ encaptype = TUNNEL_ENCAP_GUE;
+ else if (strcmp(*argv, "none") == 0)
+ encaptype = TUNNEL_ENCAP_NONE;
+ else
+ invarg("Invalid encap type.", *argv);
+ } else if (strcmp(*argv, "encap-sport") == 0) {
+ NEXT_ARG();
+ if (strcmp(*argv, "auto") == 0)
+ encapsport = 0;
+ else if (get_u16(&encapsport, *argv, 0))
+ invarg("Invalid source port.", *argv);
+ } else if (strcmp(*argv, "encap-dport") == 0) {
+ NEXT_ARG();
+ if (get_u16(&encapdport, *argv, 0))
+ invarg("Invalid destination port.", *argv);
+ } else if (strcmp(*argv, "encap-csum") == 0) {
+ encapflags |= TUNNEL_ENCAP_FLAG_CSUM;
+ } else if (strcmp(*argv, "noencap-csum") == 0) {
+ encapflags &= ~TUNNEL_ENCAP_FLAG_CSUM;
+ } else if (strcmp(*argv, "encap-udp6-csum") == 0) {
+ encapflags |= TUNNEL_ENCAP_FLAG_CSUM6;
+ } else if (strcmp(*argv, "noencap-udp6-csum") == 0) {
+ encapflags |= ~TUNNEL_ENCAP_FLAG_CSUM6;
} else
usage();
argc--; argv++;
@@ -271,6 +317,11 @@ get_failed:
addattr_l(n, 1024, IFLA_GRE_TTL, &ttl, 1);
addattr_l(n, 1024, IFLA_GRE_TOS, &tos, 1);
+ addattr16(n, 1024, IFLA_GRE_ENCAP_TYPE, encaptype);
+ addattr16(n, 1024, IFLA_GRE_ENCAP_FLAGS, encapflags);
+ addattr16(n, 1024, IFLA_GRE_ENCAP_SPORT, htons(encapsport));
+ addattr16(n, 1024, IFLA_GRE_ENCAP_DPORT, htons(encapdport));
+
return 0;
}
@@ -357,6 +408,44 @@ static void gre_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
fputs("icsum ", f);
if (oflags & GRE_CSUM)
fputs("ocsum ", f);
+
+ if (tb[IFLA_GRE_ENCAP_TYPE] &&
+ *(__u16 *)RTA_DATA(tb[IFLA_GRE_ENCAP_TYPE]) != TUNNEL_ENCAP_NONE) {
+ __u16 type = rta_getattr_u16(tb[IFLA_GRE_ENCAP_TYPE]);
+ __u16 flags = rta_getattr_u16(tb[IFLA_GRE_ENCAP_FLAGS]);
+ __u16 sport = rta_getattr_u16(tb[IFLA_GRE_ENCAP_SPORT]);
+ __u16 dport = rta_getattr_u16(tb[IFLA_GRE_ENCAP_DPORT]);
+
+ fputs("encap ", f);
+ switch (type) {
+ case TUNNEL_ENCAP_FOU:
+ fputs("fou ", f);
+ break;
+ case TUNNEL_ENCAP_GUE:
+ fputs("gue ", f);
+ break;
+ default:
+ fputs("unknown ", f);
+ break;
+ }
+
+ if (sport == 0)
+ fputs("encap-sport auto ", f);
+ else
+ fprintf(f, "encap-sport %u", ntohs(sport));
+
+ fprintf(f, "encap-dport %u ", ntohs(dport));
+
+ if (flags & TUNNEL_ENCAP_FLAG_CSUM)
+ fputs("encap-csum ", f);
+ else
+ fputs("noencap-csum ", f);
+
+ if (flags & TUNNEL_ENCAP_FLAG_CSUM6)
+ fputs("encap-csum6 ", f);
+ else
+ fputs("noencap-csum6 ", f);
+ }
}
static void gre_print_help(struct link_util *lu, int argc, char **argv,
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH v2 iproute2 4/5] ip link: Add support for remote checksum offload
From: Tom Herbert @ 2014-11-05 18:06 UTC (permalink / raw)
To: stephen, davem, netdev
In-Reply-To: <1415210788-8058-1-git-send-email-therbert@google.com>
This patch adds support to remote checksum checksum offload
confinguration for IPIP, SIT, and GRE tunnels. This patch
adds a [no]encap-remcsum to ip link command which applicable
when configured tunnels that use GUE.
http://tools.ietf.org/html/draft-herbert-remotecsumoffload-00
Example:
ip link add name tun1 type gre remote 192.168.1.1 local 192.168.1.2 \
ttl 225 encap fou encap-sport auto encap-dport 7777 encap-csum \
encap-remcsum
This would create an GRE tunnel in GUE encapsulation where the source
port is automatically selected (based on hash of inner packet),
checksums in the encapsulating UDP header are enabled (needed.for
remote checksum offload), and remote checksum is configured to
be used on the tunnel (affects TX side).
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/linux/if_tunnel.h | 1 +
ip/link_gre.c | 11 ++++++++++-
ip/link_iptnl.c | 11 ++++++++++-
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/include/linux/if_tunnel.h b/include/linux/if_tunnel.h
index 8b04f32..102ce7a 100644
--- a/include/linux/if_tunnel.h
+++ b/include/linux/if_tunnel.h
@@ -69,6 +69,7 @@ enum tunnel_encap_types {
#define TUNNEL_ENCAP_FLAG_CSUM (1<<0)
#define TUNNEL_ENCAP_FLAG_CSUM6 (1<<1)
+#define TUNNEL_ENCAP_FLAG_REMCSUM (1<<2)
/* SIT-mode i_flags */
#define SIT_ISATAP 0x0001
diff --git a/ip/link_gre.c b/ip/link_gre.c
index 47b64cb..1d78387 100644
--- a/ip/link_gre.c
+++ b/ip/link_gre.c
@@ -31,7 +31,7 @@ static void print_usage(FILE *f)
fprintf(f, " [ ttl TTL ] [ tos TOS ] [ [no]pmtudisc ] [ dev PHYS_DEV ]\n");
fprintf(f, " [ noencap ] [ encap { fou | gue | none } ]\n");
fprintf(f, " [ encap-sport PORT ] [ encap-dport PORT ]\n");
- fprintf(f, " [ [no]encap-csum ] [ [no]encap-csum6 ]\n");
+ fprintf(f, " [ [no]encap-csum ] [ [no]encap-csum6 ] [ [no]encap-remcsum ]\n");
fprintf(f, "\n");
fprintf(f, "Where: NAME := STRING\n");
fprintf(f, " ADDR := { IP_ADDRESS | any }\n");
@@ -287,6 +287,10 @@ get_failed:
encapflags |= TUNNEL_ENCAP_FLAG_CSUM6;
} else if (strcmp(*argv, "noencap-udp6-csum") == 0) {
encapflags |= ~TUNNEL_ENCAP_FLAG_CSUM6;
+ } else if (strcmp(*argv, "encap-remcsum") == 0) {
+ encapflags |= TUNNEL_ENCAP_FLAG_REMCSUM;
+ } else if (strcmp(*argv, "noencap-remcsum") == 0) {
+ encapflags |= ~TUNNEL_ENCAP_FLAG_REMCSUM;
} else
usage();
argc--; argv++;
@@ -445,6 +449,11 @@ static void gre_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[])
fputs("encap-csum6 ", f);
else
fputs("noencap-csum6 ", f);
+
+ if (flags & TUNNEL_ENCAP_FLAG_REMCSUM)
+ fputs("encap-remcsum ", f);
+ else
+ fputs("noencap-remcsum ", f);
}
}
diff --git a/ip/link_iptnl.c b/ip/link_iptnl.c
index 9487117..cab174f 100644
--- a/ip/link_iptnl.c
+++ b/ip/link_iptnl.c
@@ -31,7 +31,7 @@ static void print_usage(FILE *f, int sit)
fprintf(f, " [ 6rd-prefix ADDR ] [ 6rd-relay_prefix ADDR ] [ 6rd-reset ]\n");
fprintf(f, " [ noencap ] [ encap { fou | gue | none } ]\n");
fprintf(f, " [ encap-sport PORT ] [ encap-dport PORT ]\n");
- fprintf(f, " [ [no]encap-csum ] [ [no]encap-csum6 ]\n");
+ fprintf(f, " [ [no]encap-csum ] [ [no]encap-csum6 ] [ [no]encap-remcsum ]\n");
if (sit) {
fprintf(f, " [ mode { ip6ip | ipip | any } ]\n");
fprintf(f, " [ isatap ]\n");
@@ -256,6 +256,10 @@ get_failed:
encapflags |= TUNNEL_ENCAP_FLAG_CSUM6;
} else if (strcmp(*argv, "noencap-udp6-csum") == 0) {
encapflags &= ~TUNNEL_ENCAP_FLAG_CSUM6;
+ } else if (strcmp(*argv, "encap-remcsum") == 0) {
+ encapflags |= TUNNEL_ENCAP_FLAG_REMCSUM;
+ } else if (strcmp(*argv, "noencap-remcsum") == 0) {
+ encapflags &= ~TUNNEL_ENCAP_FLAG_REMCSUM;
} else if (strcmp(*argv, "6rd-prefix") == 0) {
inet_prefix prefix;
NEXT_ARG();
@@ -438,6 +442,11 @@ static void iptunnel_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[
fputs("encap-csum6 ", f);
else
fputs("noencap-csum6 ", f);
+
+ if (flags & TUNNEL_ENCAP_FLAG_REMCSUM)
+ fputs("encap-remcsum ", f);
+ else
+ fputs("noencap-remcsum ", f);
}
}
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH v2 iproute2 5/5] iproute2: Man pages for fou and gue
From: Tom Herbert @ 2014-11-05 18:06 UTC (permalink / raw)
To: stephen, davem, netdev
In-Reply-To: <1415210788-8058-1-git-send-email-therbert@google.com>
Man pages for Foo-over-UDP and Generic UDP Encapsulation receive
port configuration. gue man page links to fou one.
Signed-off-by: Tom Herbert <therbert@google.com>
---
man/man8/ip-fou.8 | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
man/man8/ip-gue.8 | 1 +
2 files changed, 77 insertions(+)
create mode 100644 man/man8/ip-fou.8
create mode 100644 man/man8/ip-gue.8
diff --git a/man/man8/ip-fou.8 b/man/man8/ip-fou.8
new file mode 100644
index 0000000..0fa22ee
--- /dev/null
+++ b/man/man8/ip-fou.8
@@ -0,0 +1,76 @@
+.TH IP\-FOU 8 "2 Nov 2014" "iproute2" "Linux"
+.SH "NAME"
+ip-fou \- Foo-over-UDP receive port configuration
+.P
+ip-gue \- Generic UDP Encapsulation receive port configuration
+.SH "SYNOPSIS"
+.sp
+.ad l
+.in +8
+.ti -8
+.B ip
+.RI "[ " OPTIONS " ]"
+.B fou
+.RI " { " COMMAND " | "
+.BR help " }"
+.sp
+.ti -8
+.BR "ip fou add"
+.B port
+.IR PORT
+.RB "{ "
+.B gue
+.RI "|"
+.B ipproto
+.IR PROTO
+.RB " }"
+.br
+.ti -8
+.BR "ip fou del"
+.B port
+.IR PORT
+.SH DESCRIPTION
+The
+.B ip fou
+commands are used to create and delete receive ports for Foo-over-UDP
+(FOU) as well as Generic UDP Encapsulation (GUE).
+.PP
+Foo-over-UDP allows encapsulating packets of an IP protocol directly
+over UDP. The receiver infers the protocol of a packet received on
+a FOU UDP port to be the protocol configured for the port.
+.PP
+Generic UDP Encapsulation (GUE) encapsulates packets of an IP protocol
+within UDP and an encapsulation header. The encapsulation header contains the
+IP protocol number for the encapsulated packet.
+.PP
+When creating a FOU or GUE receive port, the port number is specified in
+.I PORT
+argument. If FOU is used, the IP protocol number associated with the port is specified in
+.I PROTO
+argument.
+.PP
+A FOU or GUE receive port is deleted by specifying
+.I PORT
+in the delete command.
+.SH EXAMPLES
+.PP
+.SS Configure a FOU receive port for GRE bound to 7777
+.nf
+# ip fou add port 8888 ipproto 47
+.PP
+.SS Configure a FOU receive port for IPIP bound to 8888
+.nf
+# ip fou add port 8888 ipproto 4
+.PP
+.SS Configure a GUE receive port bound to 9999
+.nf
+# ip fou add port 9999 gue
+.PP
+.SS Delete the GUE receive port bound to 9999
+.nf
+# ip fou del port 9999
+.SH SEE ALSO
+.br
+.BR ip (8)
+.SH AUTHOR
+Tom Herbert <therbert@google.com>
diff --git a/man/man8/ip-gue.8 b/man/man8/ip-gue.8
new file mode 100644
index 0000000..4d2914c
--- /dev/null
+++ b/man/man8/ip-gue.8
@@ -0,0 +1 @@
+.so man8/ip-fou.8
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* Re: [PATCH] rtlwifi: Add more checks for get_btc_status callback
From: Larry Finger @ 2014-11-05 18:12 UTC (permalink / raw)
To: Mike Galbraith
Cc: Murilo Opsfelder Araujo, linux-kernel, linux-wireless, netdev,
Chaoming Li, John W. Linville, Thadeu Cascardo, troy_tan
In-Reply-To: <1415178975.5402.66.camel@marge.simpson.net>
On 11/05/2014 03:16 AM, Mike Galbraith wrote:
> On Wed, 2014-10-29 at 23:30 -0500, Larry Finger wrote:
>> On 10/29/2014 06:28 PM, Murilo Opsfelder Araujo wrote:
>>> This is a complement of commit 08054200117a95afc14c3d2ed3a38bf4e345bf78
>>> "rtlwifi: Add check for get_btc_status callback".
>>>
>>> With this patch, next-20141029 at least does not panic with rtl8192se
>>> device.
>>>
>>
>> This patch is OK, but as noted it is not complete.
>>
>> I have patches to fix all the kernel panics for rtl8192se AND rtl8192ce. There
>> are missing parts, but I would prefer submitting mine, which would conflict with
>> this one. For that reason, NACK for this one, and please apply the set I am
>> submitting now.
>
> It's all in there now, but my RTL8191SEvB is still dead. Squabbling
> with it isn't going all that well either.
>
> As soon as 38506ece rtlwifi: rtl_pci: Start modification for new drivers
> is applied, explosions appear. Subsequently applying...
>
> 08054200 rtlwifi: Add check for get_btc_status callback
> c0386f15 rtlwifi: rtl8192ce: rtl8192de: rtl8192se: Fix handling for missing get_btc_status
> 50147969 rtlwifi: rtl8192se: Fix duplicate calls to ieee80211_register_hw()
> 30c5ccc6 rtlwifi: rtl8192se: Add missing section to read descriptor setting
> 75a916e1 rtlwifi: rtl8192se: Fix firmware loading
>
> ...fixes that mess up, but leaves the interface dead in the same manner
> as if nothing has been reverted. So it _seems_ the bustage lurks in
> 38506ece somewhere. Too bad it's non-dinky, and written in wifi-ese :)
Yes, I am aware that rtl8192se is failing, and now that I am back from vacation,
I am working on the problem. If you want to use the driver with kernel 3.18,
clone the repo at http://github.com/lwfinger/rtlwifi_new.git and build and
install either the master or kernel_version branches. Both work.
I am in the process of trying to find what the crucial difference is between
that repo and the kernel version.
Larry
^ permalink raw reply
* M_CAN message RAM initialization AppNote - was: Re: [PATCH V3 3/3] can: m_can: workaround for transmit data less than 4 bytes
From: Oliver Hartkopp @ 2014-11-05 18:15 UTC (permalink / raw)
To: Marc Kleine-Budde, Dong Aisheng, linux-can
Cc: wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <545A3451.2090302@pengutronix.de>
Hi all,
just to close this application note relevant point ...
I got an answer from Florian Hartwich (Mr. CAN) from Bosch regarding the bit
error detection found by Dong Aisheng.
The relevant interrupts IR.BEU or IR.BEC monitor the message RAM:
Bit 21 BEU: Bit Error Uncorrected
Message RAM bit error detected, uncorrected. Controlled by input signal
m_can_aeim_berr[1] generated by an optional external parity / ECC logic
attached to the Message RAM. An uncorrected Message RAM bit error sets
CCCR.INIT to ‘1’. This is done to avoid transmission of corrupted data.
0= No bit error detected when reading from Message RAM
1= Bit error detected, uncorrected (e.g. parity logic)
Bit 20 BEC: Bit Error Corrected
Message RAM bit error detected and corrected. Controlled by input signal
m_can_aeim_berr[0] generated by an optional external parity / ECC logic
attached to the Message RAM.
0= No bit error detected when reading from Message RAM
1= Bit error detected and corrected (e.g. ECC)
---
The Message RAM is usually equipped with a parity or ECC functionality.
But RAM cells suffer a hardware reset and can therefore hold arbitrary content
at startup - including parity and/or ECC bits.
So when you write only the CAN ID and the first four bytes the last four bytes
remain untouched. Then the M_CAN starts to read in 32bit words from the start
of the Tx Message element. So it is very likely to trigger the message RAM
error when reading the uninitialized 32bit word from the last four bytes.
Finally it turns out that an initial writing (with any kind of data) to the
entire message RAM is mandatory to create valid parity/ECC checksums.
That's it.
Regards,
Oliver
^ permalink raw reply
* Re: Can ndo_select_queue save data in skb->cb?
From: Eric Dumazet @ 2014-11-05 18:16 UTC (permalink / raw)
To: James Yonan; +Cc: netdev
In-Reply-To: <545A64EC.309@openvpn.net>
On Wed, 2014-11-05 at 10:57 -0700, James Yonan wrote:
> Is it permissible for a net driver's ndo_select_queue method to save
> data in skb->cb for later use in ndo_start_xmit?
>
> Also, is it necessary for users of skb->cb to zero out their private
> data after use to prevent it from being misinterpreted by other layers?
> I noticed some commits in the log (such as 462fb2) are zeroing out the
> skb->cb area for this reason.
Its ok to use skb->cb[] from ndo_select_queue()
Look at bond_select_queue() for such a case.
You do not need to cleanup skb->cb[] to zero before giving skb to the
driver.
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: reclaim TX skbs only when released by the HW
From: Karl Beldan @ 2014-11-05 18:31 UTC (permalink / raw)
To: Ezequiel Garcia
Cc: David Miller, Ian Campbell, Karl Beldan, netdev, Eric Dumazet,
Sebastian Hesselbarth
In-Reply-To: <20141105150521.GA25354@magnum.frso.rivierawaves.com>
On Wed, Nov 05, 2014 at 04:05:21PM +0100, Karl Beldan wrote:
> On Wed, Nov 05, 2014 at 11:46:16AM -0300, Ezequiel Garcia wrote:
> > Hi Karl,
> >
> > On 11/05/2014 11:32 AM, Karl Beldan wrote:> From: Karl Beldan <karl.beldan@rivierawaves.com>
> > >
> > > ATM, txq_reclaim will dequeue and free an skb for each tx desc released
> > > by the hw that has TX_LAST_DESC set. However, in case of TSO, each
> > > hw desc embedding the last part of a segment has TX_LAST_DESC set,
> > > losing the one-to-one 'last skb frag'/'TX_LAST_DESC set' correspondance,
> > > which causes data corruption.
> > >
> > > Fix this by checking TX_ENABLE_INTERRUPT instead of TX_LAST_DESC, and
> > > warn when trying to dequeue from an empty txq (which can be symptomatic
> > > of releasing skbs prematurely).
> > >
> > > Fixes: 3ae8f4e0b98 ('net: mv643xx_eth: Implement software TSO')
> >
> > Although your change makes sense, this isn't fixing the issue for me,
> > neither did the previous one.
> >
> This change fixes a serious issue.
> On my side I can now trigger misc NFS and md5sums errors very easily,
> which I haven't detected so far with it applied.
> Are you running little endian ? Do you have the tso alignment fix
> a63ba13e (I don't expect it to be required but I don't know what SoC you
> are using) ? I suppose you are running with all 3 fixes applied.
>
Also, I haven't checked SMP issues and I only have one core, if you are
using SMP it might be worth looking into that, maybe try running on one
core only (I only have an MV78200).
Karl
^ permalink raw reply
* Re: Can ndo_select_queue save data in skb->cb?
From: Cong Wang @ 2014-11-05 18:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: James Yonan, netdev
In-Reply-To: <1415211391.13896.10.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, Nov 5, 2014 at 10:16 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2014-11-05 at 10:57 -0700, James Yonan wrote:
>> Is it permissible for a net driver's ndo_select_queue method to save
>> data in skb->cb for later use in ndo_start_xmit?
>>
>> Also, is it necessary for users of skb->cb to zero out their private
>> data after use to prevent it from being misinterpreted by other layers?
>> I noticed some commits in the log (such as 462fb2) are zeroing out the
>> skb->cb area for this reason.
>
> Its ok to use skb->cb[] from ndo_select_queue()
>
> Look at bond_select_queue() for such a case.
>
> You do not need to cleanup skb->cb[] to zero before giving skb to the
> driver.
>
That is only because qdisc layer saves data for bond,
which means if you have more data to save, you have to put
more into qdisc CB, it is just ugly.
^ permalink raw reply
* guten Tag,
From: Lubben Hendrik @ 2014-11-05 17:39 UTC (permalink / raw)
To: netdev
guten Tag,
Mein Name ist Lubben Hendrik und ich arbeite mit der Finanz- Haus hier in der Niederlande.
Ich fand Ihre Adresse durch meinen Ländern internationale Web Verzeichnis. Bei unserem letzten Treffen und Prüfung der Bankkonten
hier in den Niederlanden gefunden meine Abteilung ein ruhendes Konto mit einem enorme Summe von US $6.500.000,00
( sechs Millionen fünfhunderttausend USDollar ), die von verstorbenen Herrn Williams aus England abgelagert wurde .
Vor seinem Tod übernahm er die Summe von US $6.500.000,00 ( sechs Millionen fünfhunderttausend USDollar)an eine Bank hier in den Niederlanden. von unserem
Untersuchung hatte er keinen Empfänger oder nächsten Angehörigen , diese Mittel zu erreichen.
Aufgrund unserer finanziellen Hausordnung nur ein Ausländer kann als Stand-nächsten Verwandten oder nächsten Angehörigen . Der Antrag eines
Ausländers als nächsten Angehörigen ist die Basis auf der Tatsache, dass der Einleger ein Ausländer und jemand
in der war Niederlande kann nicht als die nächsten Angehörigen zu stehen.
Ich brauche Ihre Erlaubnis als nächster Verwandter oder nächsten Angehörigen unserer Verstorbenen
Kunden , so dass die Mittel freigegeben werden kann und Transfer zu Ihrem Konto , am Ende der Transaktion 40% wird für Sie sein und 60 % werden
für mich und meine Kollegen.
Wir brauchen ein ausländisches Konto . Ich immer noch auf die finanzielle Haus zu arbeiten , und das ist
der eigentliche Grund , dass ich eine zweite Partei oder Person brauchen ,zu stehen und zu arbeiten
mit mir und gelten für die Bank hier in den Niederlanden , wie die nächsten Angehörigen.
Ich habe in meinem Besitz alle notwendigen Unterlagen zu haben, diese Transaktion erfolgreich durchgeführt .
Weitere Informationen werden nach dem Eingang Ihrer Aufforderung zur Verfügung gestellt werden
Reaktion und ich möchte , dass Sie wissen , dass es kein Risiko. ich werde müssen uns zusammen zu arbeiten ,
wenn Sie interessiert sind , und ich versichere Ihnen, dass ich werden alle nützlichen Informationen und Dokumentation wie diese
Unternehmen zu schaffen braucht dringend Aufmerksamkeit,da es keine viel Zeit zu verlieren.
Bitte schreiben Sie mir direkt mit Ihrem Namen , Adresse , Telefon-und Faxnummer
auf diese E-Mail(lubbenhendrik1@aol.com)so kann ich erklären die Verfahren .
Grüße
Lubben Hendrik
^ permalink raw reply
* [PATCH] net: dsa: slave: Fix autoneg for phys on switch MDIO bus
From: Andrew Lunn @ 2014-11-05 18:47 UTC (permalink / raw)
To: davem, f.fainelli; +Cc: netdev, Andrew Lunn
When the ports phys are connected to the switches internal MDIO bus,
we need to connect the phy to the slave netdev, otherwise
auto-negotiation etc, does not work.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
Hi Florian
Is this the right fix?
What i found is that ports on mv88E6171 we coming up as 10/half. If i
forced a renegotiation with ethtool -r lan0, the phy would then goto
1000/full.
The code for phys on internal switch MDIO buses never connect the phy
to the device, only phys listed in DT get connected via
of_phy_connect(). By connecting the phy, the state machine is active
and does an autoneg when the slave interface is opened.
net/dsa/slave.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 6d1817449c36..ab03e00ffe8f 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -489,11 +489,14 @@ static void dsa_slave_phy_setup(struct dsa_slave_priv *p,
/* We could not connect to a designated PHY, so use the switch internal
* MDIO bus instead
*/
- if (!p->phy)
+ if (!p->phy) {
p->phy = ds->slave_mii_bus->phy_map[p->port];
- else
+ phy_connect_direct(slave_dev, p->phy, dsa_slave_adjust_link,
+ p->phy_interface);
+ } else {
pr_info("attached PHY at address %d [%s]\n",
p->phy->addr, p->phy->drv->name);
+ }
}
int dsa_slave_suspend(struct net_device *slave_dev)
--
2.1.3
^ permalink raw reply related
* Re: getting rid of ->splice_write?
From: Al Viro @ 2014-11-05 18:49 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Miklos Szeredi, linux-fsdevel, netdev
In-Reply-To: <20140922173053.GA13109@infradead.org>
On Mon, Sep 22, 2014 at 10:30:53AM -0700, Christoph Hellwig wrote:
> Currently only /dev/null, fusedev and the socket code have a
> splice_write implementation that isn't iter_file_splice_write, and
> it seems like these three could easily be switched over if they
> implemented a ->write_iter.
Not really. A minor nitpick is that you've missed port_fops_splice_write(),
but the real bitch isn't that and not even the sockets (see the fun with
iov_iter sendmsg/recvmsg work getting resurrected). It's that NULL
->splice_write() means default_file_splice_write. IOW, you'd need either
->write_iter() for _everything_ (with support of bvec-backed ones included,
since that's what iter_file_splice_write() will feed to ->write_iter()),
or you need to have do_splice_from() check if ->write_iter is NULL and
go for default_file_splice_write() instead of iter_file_splice_write().
The latter might be doable, but the former is really over the top - for
that we'd need to touch every driver instance of ->write() out there.
You want to do that, it's your funeral...
> Similarly it seems to be like we could kill ->splice_read by
> implementing an equivalent iteration over ->read_iter.
Hard to do. I agree that we want to, but it'll take quite a bit of work
on iov_iter primitives, I'm afraid. At the very least, we want a variant
of iov_iter that could steal pages. Don't forget that a large part of
the rationale behind splice_read was the ability to play zero-copy games.
I'm not sure if it will happen this cycle; there's more than enough fun
on the net/* side. _If_ that ends up done faster than I expect it to be,
->splice_read() is the obvious next target.
^ permalink raw reply
* Re: Can ndo_select_queue save data in skb->cb?
From: Eric Dumazet @ 2014-11-05 18:53 UTC (permalink / raw)
To: Cong Wang; +Cc: James Yonan, netdev
In-Reply-To: <CAHA+R7M2k8_9C8=kdAJT1nSFDhKfV2HwvTo0nX-tVDJQvXjy+w@mail.gmail.com>
On Wed, 2014-11-05 at 10:38 -0800, Cong Wang wrote:
> That is only because qdisc layer saves data for bond,
> which means if you have more data to save, you have to put
> more into qdisc CB, it is just ugly.
Right, using skb->cb[] is ugly, dangerous, and all this.
If you can, avoiding it is safer.
Note that I pointed to the bonding case for a legal case,
I had no time to do a full explanation, feel free to do so ;)
^ permalink raw reply
* Payment
From: Finance Department @ 2014-11-05 18:49 UTC (permalink / raw)
Dear Recipient,
You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146 by office of the ministry of finance UK.Send us your personal details to deliver your funds.
Gloria Peter
^ permalink raw reply
* [PATCH 0/3] Add support for switch on Armanda 370 RD
From: Andrew Lunn @ 2014-11-05 19:01 UTC (permalink / raw)
To: davem, Jason Cooper
Cc: netdev, linux ARM, Thomas Petazzoni, tawfik, maxime.ripard,
Andrew Lunn
This patchset adds support for the switch chip found on the Marvell
370 RD board. The first patch extends the current mv88e6171 driver to
also support the mv88e6172. The second patch described the switch in
the device tree of the board, and the last patch enables require build
options in mvebu_v7_defconfig.
Davem should take patch #1
Jason Cooper should take patch #2 and #3.
Andrew Lunn (3):
dsa: mv88e6171: Add support for mv88e6172
mvebu: 370 RD: Add support for the switch
mvebu: defconfig: Enable the mv88E6171 switch driver
arch/arm/boot/dts/armada-370-rd.dts | 49 ++++++++++++++++++++++++++++++++----
arch/arm/boot/dts/armada-370-xp.dtsi | 2 +-
arch/arm/configs/mvebu_v7_defconfig | 2 ++
drivers/net/dsa/Kconfig | 6 ++---
drivers/net/dsa/mv88e6171.c | 5 +++-
5 files changed, 54 insertions(+), 10 deletions(-)
--
2.1.3
^ permalink raw reply
* [PATCH 2/3] mvebu: 370 RD: Add support for the switch
From: Andrew Lunn @ 2014-11-05 19:02 UTC (permalink / raw)
To: davem, Jason Cooper
Cc: netdev, linux ARM, Thomas Petazzoni, tawfik, maxime.ripard,
Andrew Lunn
In-Reply-To: <1415214121-29286-1-git-send-email-andrew@lunn.ch>
The 370 rd has a 7 port, mv88E6182 switch, connected to eth1. Add a
fixed-link subnode to the ethernet device tree node, to force
gigabit/full duplex. Add a dsa node, with describing the four used
ports. This requires adding an alias to the mdio node, so it can be
referenced as a phandle.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/boot/dts/armada-370-rd.dts | 49 ++++++++++++++++++++++++++++++++----
arch/arm/boot/dts/armada-370-xp.dtsi | 2 +-
2 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-rd.dts b/arch/arm/boot/dts/armada-370-rd.dts
index f57a8f841498..2bb671a778db 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -85,10 +85,6 @@
phy0: ethernet-phy@0 {
reg = <0>;
};
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
};
ethernet@70000 {
@@ -100,8 +96,11 @@
pinctrl-0 = <&ge1_rgmii_pins>;
pinctrl-names = "default";
status = "okay";
- phy = <&phy1>;
phy-mode = "rgmii-id";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
};
mvsdio@d4000 {
@@ -173,4 +172,44 @@
};
};
};
+
+ dsa@0 {
+ compatible = "marvell,dsa";
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ dsa,ethernet = <ð1>;
+ dsa,mii-bus = <&mdio>;
+
+ switch@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x10 0>; /* MDIO address 16, switch 0 in tree */
+
+ port@0 {
+ reg = <0>;
+ label = "lan0";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan2";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan3";
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "cpu";
+ };
+ };
+ };
};
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 83286ec9702c..4d84ca981fe0 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -232,7 +232,7 @@
status = "disabled";
};
- mdio {
+ mdio: mdio {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,orion-mdio";
--
2.1.3
^ permalink raw reply related
* [PATCH 1/3] dsa: mv88e6171: Add support for mv88e6172
From: Andrew Lunn @ 2014-11-05 19:01 UTC (permalink / raw)
To: davem, Jason Cooper
Cc: netdev, linux ARM, Thomas Petazzoni, tawfik, maxime.ripard,
Andrew Lunn
In-Reply-To: <1415214121-29286-1-git-send-email-andrew@lunn.ch>
The mv88e6172 is very similar to the mv88e6171. So extend the
mv88e6171 driver to support it.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/Kconfig | 6 +++---
drivers/net/dsa/mv88e6171.c | 5 ++++-
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 9234d808cbb3..69bed5b2f078 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -37,13 +37,13 @@ config NET_DSA_MV88E6123_61_65
ethernet switch chips.
config NET_DSA_MV88E6171
- tristate "Marvell 88E6171 ethernet switch chip support"
+ tristate "Marvell 88E6171/6172 ethernet switch chip support"
select NET_DSA
select NET_DSA_MV88E6XXX
select NET_DSA_TAG_EDSA
---help---
- This enables support for the Marvell 88E6171 ethernet switch
- chip.
+ This enables support for the Marvell 88E6171/6172 ethernet switch
+ chips.
config NET_DSA_BCM_SF2
tristate "Broadcom Starfighter 2 Ethernet switch support"
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index 1020a7af67cf..d9919ce2b005 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -1,4 +1,4 @@
-/* net/dsa/mv88e6171.c - Marvell 88e6171 switch chip support
+/* net/dsa/mv88e6171.c - Marvell 88e6171/8826172 switch chip support
* Copyright (c) 2008-2009 Marvell Semiconductor
* Copyright (c) 2014 Claudio Leite <leitec@staticky.com>
*
@@ -29,6 +29,8 @@ static char *mv88e6171_probe(struct device *host_dev, int sw_addr)
if (ret >= 0) {
if ((ret & 0xfff0) == 0x1710)
return "Marvell 88E6171";
+ if ((ret & 0xfff0) == 0x1720)
+ return "Marvell 88E6172";
}
return NULL;
@@ -409,3 +411,4 @@ struct dsa_switch_driver mv88e6171_switch_driver = {
};
MODULE_ALIAS("platform:mv88e6171");
+MODULE_ALIAS("platform:mv88e6172");
--
2.1.3
^ permalink raw reply related
* [PATCH 3/3] mvebu: defconfig: Enable the mv88E6171 switch driver
From: Andrew Lunn @ 2014-11-05 19:02 UTC (permalink / raw)
To: davem, Jason Cooper
Cc: netdev, linux ARM, Thomas Petazzoni, tawfik, maxime.ripard,
Andrew Lunn
In-Reply-To: <1415214121-29286-1-git-send-email-andrew@lunn.ch>
This switch is used by the 370-rd. Enable it and support for
fixed-link phy configuration.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
arch/arm/configs/mvebu_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
index ed0a0d1be0f3..8548eee5cbeb 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -59,10 +59,12 @@ CONFIG_ATA=y
CONFIG_AHCI_MVEBU=y
CONFIG_SATA_MV=y
CONFIG_NETDEVICES=y
+CONFIG_NET_DSA_MV88E6171=y
CONFIG_MV643XX_ETH=y
CONFIG_MVNETA=y
CONFIG_MVPP2=y
CONFIG_MARVELL_PHY=y
+CONFIG_FIXED_PHY=y
CONFIG_MWIFIEX=y
CONFIG_MWIFIEX_SDIO=y
CONFIG_INPUT_EVDEV=y
--
2.1.3
^ permalink raw reply related
* Re: [PATCH] net: mv643xx_eth: reclaim TX skbs only when released by the HW
From: Ian Campbell @ 2014-11-05 19:04 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ezequiel Garcia, Karl Beldan, David Miller, Karl Beldan, netdev,
Sebastian Hesselbarth
In-Reply-To: <1415202075.12206.0.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, 2014-11-05 at 07:41 -0800, Eric Dumazet wrote:
> On Wed, 2014-11-05 at 11:46 -0300, Ezequiel Garcia wrote:
> > Hi Karl,
> >
> > On 11/05/2014 11:32 AM, Karl Beldan wrote:> From: Karl Beldan <karl.beldan@rivierawaves.com>
> > >
> > > ATM, txq_reclaim will dequeue and free an skb for each tx desc released
> > > by the hw that has TX_LAST_DESC set. However, in case of TSO, each
> > > hw desc embedding the last part of a segment has TX_LAST_DESC set,
> > > losing the one-to-one 'last skb frag'/'TX_LAST_DESC set' correspondance,
> > > which causes data corruption.
> > >
> > > Fix this by checking TX_ENABLE_INTERRUPT instead of TX_LAST_DESC, and
> > > warn when trying to dequeue from an empty txq (which can be symptomatic
> > > of releasing skbs prematurely).
> > >
> > > Fixes: 3ae8f4e0b98 ('net: mv643xx_eth: Implement software TSO')
> >
> > Although your change makes sense, this isn't fixing the issue for me,
> > neither did the previous one.
> >
> > Ian: Can you double check that you have corruption *without* the patch,
> > and that the patch fixes the issue?
Yes, doing md5sum on an NFS mount with 18 files in it I see 8-9
corrupted ones without any patch applied and none with Karl's previous
one from <20141104142020.GA6728@magnum.frso.rivierawaves.com> in place.
This was consistent over repeated invocations of md5sum (mounting and
unmounting around each one).
I've just confirmed this again to be sure.
The system is a QNAP TS-41x (armel, Feroceon 88FR131)
> Have you also applied my patch ?
I've only applied that one patch from Karl onto the 3.16.7 kernel which
is currently in Debian. Debian hasn't got any other mv643xx patches
applied.
I'm building now with Karl's latest patch from
<1415197979-1702-1-git-send-email-karl.beldan@gmail.com> instead.
Ian.
^ 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