* Re: [PATCH 3/3] net: rxrpc: Replace time_t type with time64_t type
From: David Howells @ 2017-08-09 15:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: dhowells, Baolin Wang, David Miller, james.l.morris,
Serge E. Hallyn, marc.dionne, Dan Carpenter, Jason A. Donenfeld,
Mark Brown, keyrings, Linux Kernel Mailing List, LSM List,
Networking
In-Reply-To: <CAK8P3a2STbhgFB5kbVTZqAgY70K_GCaWgj6Kqs4RJOOt2oSd-g@mail.gmail.com>
Arnd Bergmann <arnd@arndb.de> wrote:
> Ah, I'm slowly starting to understand how this fits together. So you can add
> a key either through key_add() from local user space, or through an rxrpc
> socket.
No, you can't add keys through an rxrpc socket.
There are three 'classes' of key:
(1) Client keys (type rxrpc). These must be added by add_key() by userspace
(but could also be acquired by upcalling to /sbin/request-key) and then
the kernel calls request_key() to locate them on entry through either a
kafs inode/file operation or through sendmsg() to an AF_RXRPC socket.
(2) Server keys (type rxrpc_s). These are created by userspace and are
presented to an AF_RXRPC server socket by calling setsockopt(). The
server uses these to validate/decrypt the token passed by a RESPONSE
packet.
(3) Service connection keys (type rxrpc). These are created internally by
AF_RXRPC after a successful challenge/response negotiation to hold the
security details so that we have a struct key to pass around that
corresponds to the key in (1).
David
^ permalink raw reply
* [PATCH v3 iproute2] lib: Dump ext-ack string by default
From: David Ahern @ 2017-08-09 15:43 UTC (permalink / raw)
To: netdev, stephen; +Cc: David Ahern
In time, errfn can be implemented for link, route, etc commands to
give a much more detailed response (e.g., point to the attribute
that failed). Doing so is much more complicated to process the
message and convert attribute ids to names.
In any case the error string returned by the kernel should be dumped
to the user, so make that happen now.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
v3
- add ending '.' if string does not have one
v2
- check that errmsg is non-null
lib/libnetlink.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 145de2cb0ccf..81a344abff27 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -61,7 +61,6 @@ static int err_attr_cb(const struct nlattr *attr, void *data)
return MNL_CB_OK;
}
-
/* dump netlink extended ack error message */
static int nl_dump_ext_err(const struct nlmsghdr *nlh, nl_ext_ack_fn_t errfn)
{
@@ -72,9 +71,6 @@ static int nl_dump_ext_err(const struct nlmsghdr *nlh, nl_ext_ack_fn_t errfn)
const char *errmsg = NULL;
uint32_t off = 0;
- if (!errfn)
- return 0;
-
/* no TLVs, nothing to do here */
if (!(nlh->nlmsg_flags & NLM_F_ACK_TLVS))
return 0;
@@ -99,7 +95,19 @@ static int nl_dump_ext_err(const struct nlmsghdr *nlh, nl_ext_ack_fn_t errfn)
err_nlh = &err->msg;
}
- return errfn(errmsg, off, err_nlh);
+ if (errfn)
+ return errfn(errmsg, off, err_nlh);
+
+ if (errmsg && *errmsg != '\0') {
+ fprintf(stderr, "Error: %s", errmsg);
+ if (errmsg[strlen(errmsg) - 1] != '.')
+ fprintf(stderr, ".");
+ fprintf(stderr, "\n");
+
+ return 1;
+ }
+
+ return 0;
}
#else
#warning "libmnl required for error support"
--
2.1.4
^ permalink raw reply related
* [PATCH net-next] rtnelink: Move link dump consistency check out of the loop
From: Jakub Sitnicki @ 2017-08-09 15:39 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller
Calls to rtnl_dump_ifinfo() are protected by RTNL lock. So are the
{list,unlist}_netdevice() calls where we bump the net->dev_base_seq
number.
For this reason net->dev_base_seq can't change under out feet while
we're looping over links in rtnl_dump_ifinfo(). So move the check for
net->dev_base_seq change (since the last time we were called) out of the
loop.
This way we avoid giving a wrong impression that there are concurrent
updates to the link list going on while we're iterating over them.
Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
---
net/core/rtnetlink.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 9201e36..6b7888e 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1644,8 +1644,6 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
s_h = cb->args[0];
s_idx = cb->args[1];
- cb->seq = net->dev_base_seq;
-
/* A hack to preserve kernel<->userspace interface.
* The correct header is ifinfomsg. It is consistent with rtnl_getlink.
* However, before Linux v3.9 the code here assumed rtgenmsg and that's
@@ -1691,8 +1689,6 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
goto out_err;
}
-
- nl_dump_check_consistent(cb, nlmsg_hdr(skb));
cont:
idx++;
}
@@ -1702,6 +1698,8 @@ static int rtnl_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb)
out_err:
cb->args[1] = idx;
cb->args[0] = h;
+ cb->seq = net->dev_base_seq;
+ nl_dump_check_consistent(cb, nlmsg_hdr(skb));
return err;
}
--
2.9.4
^ permalink raw reply related
* [PATCH iproute2 net-next v2 2/3] iproute: add support for SRv6 local segment processing
From: David Lebrun @ 2017-08-09 15:33 UTC (permalink / raw)
To: netdev; +Cc: David Lebrun
In-Reply-To: <20170809153326.29599-1-david.lebrun@uclouvain.be>
This patch adds support for the seg6local lightweight tunnel
("ip route add ... encap seg6local ...").
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
---
ip/iproute.c | 2 +-
ip/iproute_lwtunnel.c | 208 ++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 209 insertions(+), 1 deletion(-)
diff --git a/ip/iproute.c b/ip/iproute.c
index cb695ad..7a37df5 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -100,7 +100,7 @@ static void usage(void)
fprintf(stderr, "TIME := NUMBER[s|ms]\n");
fprintf(stderr, "BOOL := [1|0]\n");
fprintf(stderr, "FEATURES := ecn\n");
- fprintf(stderr, "ENCAPTYPE := [ mpls | ip | ip6 | seg6 ]\n");
+ fprintf(stderr, "ENCAPTYPE := [ mpls | ip | ip6 | seg6 | seg6local ]\n");
fprintf(stderr, "ENCAPHDR := [ MPLSLABEL | SEG6HDR ]\n");
fprintf(stderr, "SEG6HDR := [ mode SEGMODE ] segs ADDR1,ADDRi,ADDRn [hmac HMACKEYID] [cleanup]\n");
fprintf(stderr, "SEGMODE := [ encap | inline ]\n");
diff --git a/ip/iproute_lwtunnel.c b/ip/iproute_lwtunnel.c
index 16d2584..7dde4b2 100644
--- a/ip/iproute_lwtunnel.c
+++ b/ip/iproute_lwtunnel.c
@@ -29,6 +29,8 @@
#include <linux/seg6.h>
#include <linux/seg6_iptunnel.h>
#include <linux/seg6_hmac.h>
+#include <linux/seg6_local.h>
+#include <net/if.h>
static const char *format_encap_type(int type)
{
@@ -45,6 +47,8 @@ static const char *format_encap_type(int type)
return "bpf";
case LWTUNNEL_ENCAP_SEG6:
return "seg6";
+ case LWTUNNEL_ENCAP_SEG6_LOCAL:
+ return "seg6local";
default:
return "unknown";
}
@@ -77,6 +81,8 @@ static int read_encap_type(const char *name)
return LWTUNNEL_ENCAP_BPF;
else if (strcmp(name, "seg6") == 0)
return LWTUNNEL_ENCAP_SEG6;
+ else if (strcmp(name, "seg6local") == 0)
+ return LWTUNNEL_ENCAP_SEG6_LOCAL;
else if (strcmp(name, "help") == 0)
encap_type_usage();
@@ -121,6 +127,94 @@ static void print_encap_seg6(FILE *fp, struct rtattr *encap)
print_srh(fp, tuninfo->srh);
}
+static const char *seg6_action_names[SEG6_LOCAL_ACTION_MAX + 1] = {
+ [SEG6_LOCAL_ACTION_END] = "End",
+ [SEG6_LOCAL_ACTION_END_X] = "End.X",
+ [SEG6_LOCAL_ACTION_END_T] = "End.T",
+ [SEG6_LOCAL_ACTION_END_DX2] = "End.DX2",
+ [SEG6_LOCAL_ACTION_END_DX6] = "End.DX6",
+ [SEG6_LOCAL_ACTION_END_DX4] = "End.DX4",
+ [SEG6_LOCAL_ACTION_END_DT6] = "End.DT6",
+ [SEG6_LOCAL_ACTION_END_DT4] = "End.DT4",
+ [SEG6_LOCAL_ACTION_END_B6] = "End.B6",
+ [SEG6_LOCAL_ACTION_END_B6_ENCAP] = "End.B6.Encaps",
+ [SEG6_LOCAL_ACTION_END_BM] = "End.BM",
+ [SEG6_LOCAL_ACTION_END_S] = "End.S",
+ [SEG6_LOCAL_ACTION_END_AS] = "End.AS",
+ [SEG6_LOCAL_ACTION_END_AM] = "End.AM",
+};
+
+static const char *format_action_type(int action)
+{
+ if (action < 0 || action > SEG6_LOCAL_ACTION_MAX)
+ return "<invalid>";
+
+ return seg6_action_names[action] ?: "<unknown>";
+}
+
+static int read_action_type(const char *name)
+{
+ int i;
+
+ for (i = 0; i < SEG6_LOCAL_ACTION_MAX + 1; i++) {
+ if (!seg6_action_names[i])
+ continue;
+
+ if (strcmp(seg6_action_names[i], name) == 0)
+ return i;
+ }
+
+ return SEG6_LOCAL_ACTION_UNSPEC;
+}
+
+static void print_encap_seg6local(FILE *fp, struct rtattr *encap)
+{
+ struct rtattr *tb[SEG6_LOCAL_MAX + 1];
+ char ifbuf[IFNAMSIZ];
+ int action;
+
+ parse_rtattr_nested(tb, SEG6_LOCAL_MAX, encap);
+
+ if (!tb[SEG6_LOCAL_ACTION])
+ return;
+
+ action = rta_getattr_u32(tb[SEG6_LOCAL_ACTION]);
+
+ fprintf(fp, "action %s ", format_action_type(action));
+
+ if (tb[SEG6_LOCAL_SRH]) {
+ fprintf(fp, "srh ");
+ print_srh(fp, RTA_DATA(tb[SEG6_LOCAL_SRH]));
+ }
+
+ if (tb[SEG6_LOCAL_TABLE])
+ fprintf(fp, "table %u ", rta_getattr_u32(tb[SEG6_LOCAL_TABLE]));
+
+ if (tb[SEG6_LOCAL_NH4]) {
+ fprintf(fp, "nh4 %s ",
+ rt_addr_n2a_rta(AF_INET, tb[SEG6_LOCAL_NH4]));
+ }
+
+ if (tb[SEG6_LOCAL_NH6]) {
+ fprintf(fp, "nh6 %s ",
+ rt_addr_n2a_rta(AF_INET6, tb[SEG6_LOCAL_NH6]));
+ }
+
+ if (tb[SEG6_LOCAL_IIF]) {
+ int iif = rta_getattr_u32(tb[SEG6_LOCAL_IIF]);
+
+ fprintf(fp, "iif %s ",
+ if_indextoname(iif, ifbuf) ?: "<unknown>");
+ }
+
+ if (tb[SEG6_LOCAL_OIF]) {
+ int oif = rta_getattr_u32(tb[SEG6_LOCAL_OIF]);
+
+ fprintf(fp, "oif %s ",
+ if_indextoname(oif, ifbuf) ?: "<unknown>");
+ }
+}
+
static void print_encap_mpls(FILE *fp, struct rtattr *encap)
{
struct rtattr *tb[MPLS_IPTUNNEL_MAX+1];
@@ -290,6 +384,9 @@ void lwt_print_encap(FILE *fp, struct rtattr *encap_type,
case LWTUNNEL_ENCAP_SEG6:
print_encap_seg6(fp, encap);
break;
+ case LWTUNNEL_ENCAP_SEG6_LOCAL:
+ print_encap_seg6local(fp, encap);
+ break;
}
}
@@ -412,6 +509,114 @@ static int parse_encap_seg6(struct rtattr *rta, size_t len, int *argcp,
return 0;
}
+static int parse_encap_seg6local(struct rtattr *rta, size_t len, int *argcp,
+ char ***argvp)
+{
+ int segs_ok = 0, hmac_ok = 0, table_ok = 0, nh4_ok = 0, nh6_ok = 0;
+ int iif_ok = 0, oif_ok = 0, action_ok = 0, srh_ok = 0;
+ __u32 action = 0, table, iif, oif;
+ struct ipv6_sr_hdr *srh;
+ char **argv = *argvp;
+ int argc = *argcp;
+ char segbuf[1024];
+ inet_prefix addr;
+ __u32 hmac = 0;
+
+ while (argc > 0) {
+ if (strcmp(*argv, "action") == 0) {
+ NEXT_ARG();
+ if (action_ok++)
+ duparg2("action", *argv);
+ action = read_action_type(*argv);
+ if (!action)
+ invarg("\"action\" value is invalid\n", *argv);
+ rta_addattr32(rta, len, SEG6_LOCAL_ACTION, action);
+ } else if (strcmp(*argv, "table") == 0) {
+ NEXT_ARG();
+ if (table_ok++)
+ duparg2("table", *argv);
+ get_u32(&table, *argv, 0);
+ rta_addattr32(rta, len, SEG6_LOCAL_TABLE, table);
+ } else if (strcmp(*argv, "nh4") == 0) {
+ NEXT_ARG();
+ if (nh4_ok++)
+ duparg2("nh4", *argv);
+ get_addr(&addr, *argv, AF_INET);
+ rta_addattr_l(rta, len, SEG6_LOCAL_NH4, &addr.data,
+ addr.bytelen);
+ } else if (strcmp(*argv, "nh6") == 0) {
+ NEXT_ARG();
+ if (nh6_ok++)
+ duparg2("nh6", *argv);
+ get_addr(&addr, *argv, AF_INET6);
+ rta_addattr_l(rta, len, SEG6_LOCAL_NH6, &addr.data,
+ addr.bytelen);
+ } else if (strcmp(*argv, "iif") == 0) {
+ NEXT_ARG();
+ if (iif_ok++)
+ duparg2("iif", *argv);
+ iif = if_nametoindex(*argv);
+ if (!iif)
+ invarg("\"iif\" interface not found\n", *argv);
+ rta_addattr32(rta, len, SEG6_LOCAL_IIF, iif);
+ } else if (strcmp(*argv, "oif") == 0) {
+ NEXT_ARG();
+ if (oif_ok++)
+ duparg2("oif", *argv);
+ oif = if_nametoindex(*argv);
+ if (!oif)
+ invarg("\"oif\" interface not found\n", *argv);
+ rta_addattr32(rta, len, SEG6_LOCAL_OIF, oif);
+ } else if (strcmp(*argv, "srh") == 0) {
+ NEXT_ARG();
+ if (srh_ok++)
+ duparg2("srh", *argv);
+ if (strcmp(*argv, "segs") != 0)
+ invarg("missing \"segs\" attribute for srh\n",
+ *argv);
+ NEXT_ARG();
+ if (segs_ok++)
+ duparg2("segs", *argv);
+ strncpy(segbuf, *argv, 1024);
+ segbuf[1023] = 0;
+ if (!NEXT_ARG_OK())
+ break;
+ NEXT_ARG();
+ if (strcmp(*argv, "hmac") == 0) {
+ NEXT_ARG();
+ if (hmac_ok++)
+ duparg2("hmac", *argv);
+ get_u32(&hmac, *argv, 0);
+ } else {
+ continue;
+ }
+ } else {
+ break;
+ }
+ argc--; argv++;
+ }
+
+ if (!action) {
+ fprintf(stderr, "Missing action type\n");
+ exit(-1);
+ }
+
+ if (srh_ok) {
+ int srhlen;
+
+ srh = parse_srh(segbuf, hmac,
+ action == SEG6_LOCAL_ACTION_END_B6_ENCAP);
+ srhlen = (srh->hdrlen + 1) << 3;
+ rta_addattr_l(rta, len, SEG6_LOCAL_SRH, srh, srhlen);
+ free(srh);
+ }
+
+ *argcp = argc + 1;
+ *argvp = argv - 1;
+
+ return 0;
+}
+
static int parse_encap_mpls(struct rtattr *rta, size_t len,
int *argcp, char ***argvp)
{
@@ -771,6 +976,9 @@ int lwt_parse_encap(struct rtattr *rta, size_t len, int *argcp, char ***argvp)
case LWTUNNEL_ENCAP_SEG6:
parse_encap_seg6(rta, len, &argc, &argv);
break;
+ case LWTUNNEL_ENCAP_SEG6_LOCAL:
+ parse_encap_seg6local(rta, len, &argc, &argv);
+ break;
default:
fprintf(stderr, "Error: unsupported encap type\n");
break;
--
2.10.2
^ permalink raw reply related
* [PATCH iproute2 net-next v2 3/3] man: add documentation for seg6local lwt
From: David Lebrun @ 2017-08-09 15:33 UTC (permalink / raw)
To: netdev; +Cc: David Lebrun
In-Reply-To: <20170809153326.29599-1-david.lebrun@uclouvain.be>
This patch adds documentation in the ip-route man page
about the seg6local lightweight tunnel.
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
---
man/man8/ip-route.8.in | 62 +++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 61 insertions(+), 1 deletion(-)
diff --git a/man/man8/ip-route.8.in b/man/man8/ip-route.8.in
index fc28492..11dd9d0 100644
--- a/man/man8/ip-route.8.in
+++ b/man/man8/ip-route.8.in
@@ -177,7 +177,7 @@ throw " | " unreachable " | " prohibit " | " blackhole " | " nat " ]"
.ti -8
.IR ENCAP " := [ "
-.IR MPLS " | " IP " | " BPF " | " SEG6 " ] "
+.IR MPLS " | " IP " | " BPF " | " SEG6 " | " SEG6LOCAL " ] "
.ti -8
.IR ENCAP_MPLS " := "
@@ -221,6 +221,13 @@ throw " | " unreachable " | " prohibit " | " blackhole " | " nat " ]"
.IR KEYID " ]"
.ti -8
+.IR ENCAP_SEG6LOCAL " := "
+.B seg6local
+.BR action
+.IR SEG6_ACTION " [ "
+.IR SEG6_ACTION_PARAM " ] "
+
+.ti -8
.IR ROUTE_GET_FLAGS " := "
.BR " [ "
.BR fibmatch
@@ -674,6 +681,9 @@ is a string specifying the supported encapsulation type. Namely:
.sp
.BI seg6
- encapsulation type IPv6 Segment Routing
+.sp
+.BI seg6local
+- local SRv6 segment processing
.in -8
.I ENCAPHDR
@@ -749,6 +759,56 @@ is a set of encapsulation attributes specific to the
.in -2
.sp
+.B seg6local
+.in +2
+.IR SEG6_ACTION " [ "
+.IR SEG6_ACTION_PARAM " ] "
+- Operation to perform on matching packets.
+The following actions are currently supported (\fB4.14+ only\fR).
+.in +2
+
+.B End
+- Regular SRv6 processing as intermediate segment endpoint.
+This action only accepts packets with a non-zero Segments Left
+value. Other matching packets are dropped.
+
+.B End.X nh6
+.I NEXTHOP
+- Regular SRv6 processing as intermediate segment endpoint.
+Additionally, forward processed packets to given next-hop.
+This action only accepts packets with a non-zero Segments Left
+value. Other matching packets are dropped.
+
+.B End.DX6 nh6
+.I NEXTHOP
+- Decapsulate inner IPv6 packet and forward it to the
+specified next-hop. If the argument is set to ::, then
+the next-hop is selected according to the local selection
+rules. This action only accepts packets with either a zero Segments
+Left value or no SRH at all, and an inner IPv6 packet. Other
+matching packets are dropped.
+
+.B End.B6 srh segs
+.IR SEGMENTS " [ "
+.B hmac
+.IR KEYID " ] "
+- Insert the specified SRH immediately after the IPv6 header,
+update the DA with the first segment of the newly inserted SRH,
+then forward the resulting packet. The original SRH is not
+modified. This action only accepts packets with a non-zero
+Segments Left value. Other matching packets are dropped.
+
+.B End.B6.Encaps srh segs
+.IR SEGMENTS " [ "
+.B hmac
+.IR KEYID " ] "
+- Regular SRv6 processing as intermediate segment endpoint.
+Additionally, encapsulate the matching packet within an outer IPv6 header
+followed by the specified SRH. The destination address of the outer IPv6
+header is set to the first segment of the new SRH. The source
+address is set as described in \fBip-sr\fR(8).
+.in -4
+
.in -8
.TP
--
2.10.2
^ permalink raw reply related
* [PATCH iproute2 net-next v2 1/3] iproute: add helper functions for SRH processing
From: David Lebrun @ 2017-08-09 15:33 UTC (permalink / raw)
To: netdev; +Cc: David Lebrun
In-Reply-To: <20170809153326.29599-1-david.lebrun@uclouvain.be>
This patch adds two helper functions to print and parse
Segment Routing Headers.
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
---
ip/iproute_lwtunnel.c | 124 +++++++++++++++++++++++++++++---------------------
1 file changed, 72 insertions(+), 52 deletions(-)
diff --git a/ip/iproute_lwtunnel.c b/ip/iproute_lwtunnel.c
index 5c0c7d1..16d2584 100644
--- a/ip/iproute_lwtunnel.c
+++ b/ip/iproute_lwtunnel.c
@@ -83,24 +83,10 @@ static int read_encap_type(const char *name)
return LWTUNNEL_ENCAP_NONE;
}
-static void print_encap_seg6(FILE *fp, struct rtattr *encap)
+static void print_srh(FILE *fp, struct ipv6_sr_hdr *srh)
{
- struct rtattr *tb[SEG6_IPTUNNEL_MAX+1];
- struct seg6_iptunnel_encap *tuninfo;
- struct ipv6_sr_hdr *srh;
int i;
- parse_rtattr_nested(tb, SEG6_IPTUNNEL_MAX, encap);
-
- if (!tb[SEG6_IPTUNNEL_SRH])
- return;
-
- tuninfo = RTA_DATA(tb[SEG6_IPTUNNEL_SRH]);
- fprintf(fp, "mode %s ",
- (tuninfo->mode == SEG6_IPTUN_MODE_ENCAP) ? "encap" : "inline");
-
- srh = tuninfo->srh;
-
fprintf(fp, "segs %d [ ", srh->first_segment + 1);
for (i = srh->first_segment; i >= 0; i--)
@@ -118,6 +104,23 @@ static void print_encap_seg6(FILE *fp, struct rtattr *encap)
}
}
+static void print_encap_seg6(FILE *fp, struct rtattr *encap)
+{
+ struct rtattr *tb[SEG6_IPTUNNEL_MAX+1];
+ struct seg6_iptunnel_encap *tuninfo;
+
+ parse_rtattr_nested(tb, SEG6_IPTUNNEL_MAX, encap);
+
+ if (!tb[SEG6_IPTUNNEL_SRH])
+ return;
+
+ tuninfo = RTA_DATA(tb[SEG6_IPTUNNEL_SRH]);
+ fprintf(fp, "mode %s ",
+ (tuninfo->mode == SEG6_IPTUN_MODE_ENCAP) ? "encap" : "inline");
+
+ print_srh(fp, tuninfo->srh);
+}
+
static void print_encap_mpls(FILE *fp, struct rtattr *encap)
{
struct rtattr *tb[MPLS_IPTUNNEL_MAX+1];
@@ -290,6 +293,55 @@ void lwt_print_encap(FILE *fp, struct rtattr *encap_type,
}
}
+static struct ipv6_sr_hdr *parse_srh(char *segbuf, int hmac, bool encap)
+{
+ struct ipv6_sr_hdr *srh;
+ int nsegs = 0;
+ int srhlen;
+ char *s;
+ int i;
+
+ s = segbuf;
+ for (i = 0; *s; *s++ == ',' ? i++ : *s);
+ nsegs = i + 1;
+
+ if (!encap)
+ nsegs++;
+
+ srhlen = 8 + 16*nsegs;
+
+ if (hmac)
+ srhlen += 40;
+
+ srh = malloc(srhlen);
+ memset(srh, 0, srhlen);
+
+ srh->hdrlen = (srhlen >> 3) - 1;
+ srh->type = 4;
+ srh->segments_left = nsegs - 1;
+ srh->first_segment = nsegs - 1;
+
+ if (hmac)
+ srh->flags |= SR6_FLAG1_HMAC;
+
+ i = srh->first_segment;
+ for (s = strtok(segbuf, ","); s; s = strtok(NULL, ",")) {
+ inet_get_addr(s, NULL, &srh->segments[i]);
+ i--;
+ }
+
+ if (hmac) {
+ struct sr6_tlv_hmac *tlv;
+
+ tlv = (struct sr6_tlv_hmac *)((char *)srh + srhlen - 40);
+ tlv->tlvhdr.type = SR6_TLV_HMAC;
+ tlv->tlvhdr.len = 38;
+ tlv->hmackeyid = htonl(hmac);
+ }
+
+ return srh;
+}
+
static int parse_encap_seg6(struct rtattr *rta, size_t len, int *argcp,
char ***argvp)
{
@@ -301,10 +353,7 @@ static int parse_encap_seg6(struct rtattr *rta, size_t len, int *argcp,
int argc = *argcp;
int encap = -1;
__u32 hmac = 0;
- int nsegs = 0;
int srhlen;
- char *s;
- int i;
while (argc > 0) {
if (strcmp(*argv, "mode") == 0) {
@@ -338,17 +387,8 @@ static int parse_encap_seg6(struct rtattr *rta, size_t len, int *argcp,
argc--; argv++;
}
- s = segbuf;
- for (i = 0; *s; *s++ == ',' ? i++ : *s);
- nsegs = i + 1;
-
- if (!encap)
- nsegs++;
-
- srhlen = 8 + 16*nsegs;
-
- if (hmac)
- srhlen += 40;
+ srh = parse_srh(segbuf, hmac, encap);
+ srhlen = (srh->hdrlen + 1) << 3;
tuninfo = malloc(sizeof(*tuninfo) + srhlen);
memset(tuninfo, 0, sizeof(*tuninfo) + srhlen);
@@ -358,33 +398,13 @@ static int parse_encap_seg6(struct rtattr *rta, size_t len, int *argcp,
else
tuninfo->mode = SEG6_IPTUN_MODE_INLINE;
- srh = tuninfo->srh;
- srh->hdrlen = (srhlen >> 3) - 1;
- srh->type = 4;
- srh->segments_left = nsegs - 1;
- srh->first_segment = nsegs - 1;
-
- if (hmac)
- srh->flags |= SR6_FLAG1_HMAC;
-
- i = srh->first_segment;
- for (s = strtok(segbuf, ","); s; s = strtok(NULL, ",")) {
- inet_get_addr(s, NULL, &srh->segments[i]);
- i--;
- }
-
- if (hmac) {
- struct sr6_tlv_hmac *tlv;
-
- tlv = (struct sr6_tlv_hmac *)((char *)srh + srhlen - 40);
- tlv->tlvhdr.type = SR6_TLV_HMAC;
- tlv->tlvhdr.len = 38;
- tlv->hmackeyid = htonl(hmac);
- }
+ memcpy(tuninfo->srh, srh, srhlen);
rta_addattr_l(rta, len, SEG6_IPTUNNEL_SRH, tuninfo,
sizeof(*tuninfo) + srhlen);
+
free(tuninfo);
+ free(srh);
*argcp = argc + 1;
*argvp = argv - 1;
--
2.10.2
^ permalink raw reply related
* [PATCH iproute2 net-next v2 0/3] Add support for SRv6 local segment processing
From: David Lebrun @ 2017-08-09 15:33 UTC (permalink / raw)
To: netdev; +Cc: David Lebrun
This patch series adds support and documentation for the seg6local
lightweight tunnel, enabling to perform operations to SR-enabled packets
based on their active segment.
v2: use a table for action names
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
David Lebrun (3):
iproute: add helper functions for SRH processing
iproute: add support for SRv6 local segment processing
man: add documentation for seg6local lwt
ip/iproute.c | 2 +-
ip/iproute_lwtunnel.c | 324 +++++++++++++++++++++++++++++++++++++++++--------
man/man8/ip-route.8.in | 62 +++++++++-
3 files changed, 338 insertions(+), 50 deletions(-)
--
2.10.2
^ permalink raw reply
* Re: [PATCH 3/3] net: rxrpc: Replace time_t type with time64_t type
From: Arnd Bergmann @ 2017-08-09 15:12 UTC (permalink / raw)
To: David Howells
Cc: Baolin Wang, David Miller, james.l.morris, Serge E. Hallyn,
marc.dionne, Dan Carpenter, Jason A. Donenfeld, Mark Brown,
keyrings, Linux Kernel Mailing List, LSM List, Networking
In-Reply-To: <11686.1502285205@warthog.procyon.org.uk>
On Wed, Aug 9, 2017 at 3:26 PM, David Howells <dhowells@redhat.com> wrote:
> Arnd Bergmann <arnd@arndb.de> wrote:
>
>> Do you know which format is used in practice? Are both kad and k5 common
>> among rxrpc users?
>
> The aklog program I'm using uses the non-XDR interface to push a Kerberos 5
> ticket to the kernel, so it doesn't actually invoke rxrpc_preparse_xdr() from
> rxrpc_preparse().
Ah, I'm slowly starting to understand how this fits together. So you can add
a key either through key_add() from local user space, or through an rxrpc
socket.
>From what I can tell, the program you have at
http://people.redhat.com/~dhowells/rxrpc/klog.c will keep working beyond
2038 but not beyond 2106 on all 64-bit architectures and on those
32-bit systems that have a libc with 64-bit time_t. It could be modified
to use the xdr_rxk5 key format, which would make it use 64-bit time
values (and require the kernel fix mentioned above).
In contrast, the rxrpc socket interface would need a major rework to
support 64-bit expiration times. It receives a kerberos ticket with a
32-bit issue time
that gets used to calculate the expiry time in rxkad_decrypt_ticket, and from
there we pass it through a rxrpc_key_data_v1 into key_instantiate_and_link(),
which calls rxrpc_preparse() and that just takes the expiry out again and sticks
it into another 32-bit field in struct rxkad_key, from where it
finally gets copied
into the (now 64-bit) key_preparsed_payload->expiry field.
Does my understanding match what you intended for the interfaces? Is there
a need to extend the rxrpc socket interface to support xdr_rxk5 keys as well?
Arnd
^ permalink raw reply
* Re: [PATCH 0/4] net-next: dsa: fix flow dissection
From: Vivien Didelot @ 2017-08-09 15:07 UTC (permalink / raw)
To: John Crispin, Andrew Lunn, Florian Fainelli, David S . Miller,
Sean Wang
Cc: netdev, linux-mediatek, linux-kernel, Muciri Gatimu,
Shashidhar Lakkavalli, John Crispin
In-Reply-To: <20170809124119.24320-1-john@phrozen.org>
Hi John,
John Crispin <john@phrozen.org> writes:
> RPS and probably other kernel features are currently broken on some if not
> all DSA devices. The root cause of this is that skb_hash will call the
> flow_dissector. At this point the skb still contains the magic switch
> header and the skb->protocol field is not set up to the correct 802.3
> value yet. By the time the tag specific code is called, removing the header
> and properly setting the protocol an invalid hash is already set. In the
> case of the mt7530 this will result in all flows always having the same
> hash.
>
> Changes since RFC:
> * use a callback instead of static values
> * add cover letter
>
> John Crispin (4):
> net-next: dsa: move struct dsa_device_ops to the global header file
> net-next: dsa: add flow_dissect callback to struct dsa_device_ops
> net-next: tag_mtk: add flow_dissect callback to the ops struct
> net-next: dsa: fix flow dissection
The "net-next" tag goes into the subject-prefix, i.e.
"[PATCH net-next v3 0/4]" (this is the result of git format-patch
--subject-prefix="PATCH net-next" -v3 --cover-letter.)
The commit title prefix represents the most impacted subsystem, here
"net: dsa: xxx" would map the net/dsa/ or drivers/net/dsa directories.
Other than that, the whole patchset LGTM:
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH RFC net-next] net: Allow name change of IFF_UP interfaces
From: Vitaly Kuznetsov @ 2017-08-09 15:05 UTC (permalink / raw)
To: 吉藤英明
Cc: network dev, Linux Kernel Mailing List, David S. Miller,
Eric Dumazet, Stephen Hemminger
In-Reply-To: <CAPA1RqA0q3W-3PsqDpY8_xiBB18SCWTV1gT+BKOTqQfAA5D8Fg@mail.gmail.com>
吉藤英明 <hideaki.yoshifuji@miraclelinux.com> writes:
> 2017-08-09 19:42 GMT+09:00 Vitaly Kuznetsov <vkuznets@redhat.com>:
>> What happens is: __netvsc_vf_setup() does dev_open() for the VF device and
>> the consecutive dev_change_name() fails with -EBUSY because of the
>> (dev->flags & IFF_UP) check. The history of this code predates git so I
>> wasn't able to figure out when and why the check was added, everything
>> seems to work fine without it. dev_change_name() has only two call sites,
>> both hold rtnl_lock.
>>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> ---
>> RFC: I'm probably miossing something obvious and the check can't be just
>> dropped. Stephen suggested a different solution to the isuue:
>> https://www.spinics.net/lists/netdev/msg448243.html but it has its own
>> drawbacks.
>> ---
>> net/core/dev.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 1d75499add72..c608e233a78a 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -1186,8 +1186,6 @@ int dev_change_name(struct net_device *dev, const char *newname)
>> BUG_ON(!dev_net(dev));
>>
>> net = dev_net(dev);
>> - if (dev->flags & IFF_UP)
>> - return -EBUSY;
>>
>> write_seqcount_begin(&devnet_rename_seq);
>
> I think people expect the name won't change while up
> and I don't think it is a good idea to allow changing the
> name while the interface is up.
I understand the 'legacy' concern but at the same time we don't want to
have aftificial limitations too. Name change, in particular, doesn't
happen 'under the hood' -- someone privileged enough needs to request
the change.
Can you think of any particular real world scenarios which are broken by
the change?
--
Vitaly
^ permalink raw reply
* Re: [PATCH V4 net 0/2] ipv6: fix flowlabel issue for reset packet
From: Shaohua Li @ 2017-08-09 14:59 UTC (permalink / raw)
To: netdev, davem; +Cc: Shaohua Li
In-Reply-To: <cover.1501539150.git.shli@fb.com>
On Mon, Jul 31, 2017 at 03:19:21PM -0700, Shaohua Li wrote:
> From: Shaohua Li <shli@fb.com>
>
> Please see below tcpdump output:
> 21:00:48.109122 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 40) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [S], cksum 0x0529 (incorrect -> 0xf56c), seq 3282214508, win 43690, options [mss 65476,sackOK,TS val 2500903437 ecr 0,nop,wscale 7], length 0
> 21:00:48.109381 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 40) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [S.], cksum 0x0529 (incorrect -> 0x49ad), seq 1923801573, ack 3282214509, win 43690, options [mss 65476,sackOK,TS val 2500903437 ecr 2500903437,nop,wscale 7], length 0
> 21:00:48.109548 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [.], cksum 0x0521 (incorrect -> 0x1bdf), seq 1, ack 1, win 342, options [nop,nop,TS val 2500903437 ecr 2500903437], length 0
> 21:00:48.109823 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 62) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [P.], cksum 0x053f (incorrect -> 0xb8b1), seq 1:31, ack 1, win 342, options [nop,nop,TS val 2500903437 ecr 2500903437], length 30
> 21:00:48.109910 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [.], cksum 0x0521 (incorrect -> 0x1bc1), seq 1, ack 31, win 342, options [nop,nop,TS val 2500903437 ecr 2500903437], length 0
> 21:00:48.110043 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 56) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [P.], cksum 0x0539 (incorrect -> 0xb726), seq 1:25, ack 31, win 342, options [nop,nop,TS val 2500903438 ecr 2500903437], length 24
> 21:00:48.110173 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [.], cksum 0x0521 (incorrect -> 0x1ba7), seq 31, ack 25, win 342, options [nop,nop,TS val 2500903438 ecr 2500903438], length 0
> 21:00:48.110211 IP6 (flowlabel 0xd827f, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [F.], cksum 0x0521 (incorrect -> 0x1ba7), seq 25, ack 31, win 342, options [nop,nop,TS val 2500903438 ecr 2500903437], length 0
> 21:00:48.151099 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 32) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [.], cksum 0x0521 (incorrect -> 0x1ba6), seq 31, ack 26, win 342, options [nop,nop,TS val 2500903438 ecr 2500903438], length 0
> 21:00:49.110524 IP6 (flowlabel 0x43304, hlim 64, next-header TCP (6) payload length: 56) fec0::5054:ff:fe12:3456.55804 > fec0::5054:ff:fe12:3456.5555: Flags [P.], cksum 0x0539 (incorrect -> 0xb324), seq 31:55, ack 26, win 342, options [nop,nop,TS val 2500904438 ecr 2500903438], length 24
> 21:00:49.110637 IP6 (flowlabel 0xb34d5, hlim 64, next-header TCP (6) payload length: 20) fec0::5054:ff:fe12:3456.5555 > fec0::5054:ff:fe12:3456.55804: Flags [R], cksum 0x0515 (incorrect -> 0x668c), seq 1923801599, win 0, length 0
>
> The flowlabel of reset packet (0xb34d5) and flowlabel of normal packet
> (0xd827f) are different. This causes our router doesn't correctly close tcp
> connection. The patches try to fix the issue.
Hi Dave,
Could you please look at the patches?
Thanks,
Shaohua
>
> Thanks,
> Shaohua
>
> Shaohua Li (2):
> net: remove unnecessary rotation
> net: fix tcp reset packet flowlabel for ipv6
>
> include/net/ipv6.h | 15 ++++-----------
> net/ipv4/tcp_minisocks.c | 8 +++++++-
> net/ipv6/ip6_gre.c | 2 +-
> net/ipv6/ip6_output.c | 4 ++--
> net/ipv6/ip6_tunnel.c | 2 +-
> net/ipv6/tcp_ipv6.c | 18 +++++++++++++++++-
> 6 files changed, 32 insertions(+), 17 deletions(-)
>
> --
> 2.9.3
>
^ permalink raw reply
* Re: [PATCH] net: stmmac: Use the right logging function in stmmac_mdio_register
From: Romain Perier @ 2017-08-09 14:58 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev, linux-kernel
In-Reply-To: <20170809145651.GK30723@lunn.ch>
Hi Andrew,
Le 09/08/2017 à 16:56, Andrew Lunn a écrit :
> On Wed, Aug 09, 2017 at 04:40:19PM +0200, Romain Perier wrote:
>> @@ -285,14 +286,14 @@ int stmmac_mdio_register(struct net_device *ndev)
>> irq_str = irq_num;
>> break;
>> }
>> - netdev_info(ndev, "PHY ID %08x at %d IRQ %s (%s)%s\n",
>> + dev_info(dev, "PHY ID %08x at %d IRQ %s (%s)%s\n",
>> phydev->phy_id, addr, irq_str, phydev_name(phydev),
>> act ? " active" : "");
> Hi Romain
>
> phy_attached_print() would be better.
>
> Andrew
Ok, I did not know this function, good to know. I will investigate
Thanks,
Romain
^ permalink raw reply
* Re: [PATCH] net: stmmac: Use the right logging function in stmmac_mdio_register
From: Andrew Lunn @ 2017-08-09 14:56 UTC (permalink / raw)
To: Romain Perier; +Cc: Giuseppe Cavallaro, Alexandre Torgue, netdev, linux-kernel
In-Reply-To: <20170809144019.17975-1-romain.perier@collabora.com>
On Wed, Aug 09, 2017 at 04:40:19PM +0200, Romain Perier wrote:
> @@ -285,14 +286,14 @@ int stmmac_mdio_register(struct net_device *ndev)
> irq_str = irq_num;
> break;
> }
> - netdev_info(ndev, "PHY ID %08x at %d IRQ %s (%s)%s\n",
> + dev_info(dev, "PHY ID %08x at %d IRQ %s (%s)%s\n",
> phydev->phy_id, addr, irq_str, phydev_name(phydev),
> act ? " active" : "");
Hi Romain
phy_attached_print() would be better.
Andrew
^ permalink raw reply
* Re: [PATCH iproute2 net-next 2/3] iproute: add support for SRv6 local segment processing
From: David Lebrun @ 2017-08-09 14:53 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20170809074316.3acaafa1@xeon-e3>
[-- Attachment #1.1: Type: text/plain, Size: 136 bytes --]
On 08/09/2017 04:43 PM, Stephen Hemminger wrote:
> Why is this not a table instead of code?
Fair point, will send a v2.
David
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply
* Re: [PATCH iproute2 net-next 2/3] iproute: add support for SRv6 local segment processing
From: Stephen Hemminger @ 2017-08-09 14:43 UTC (permalink / raw)
To: David Lebrun; +Cc: netdev
In-Reply-To: <20170809131701.21304-3-david.lebrun@uclouvain.be>
On Wed, 9 Aug 2017 15:17:00 +0200
David Lebrun <david.lebrun@uclouvain.be> wrote:
> +
> +static int read_action_type(const char *name)
> +{
> + if (strcmp(name, "End") == 0)
> + return SEG6_LOCAL_ACTION_END;
> + else if (strcmp(name, "End.X") == 0)
> + return SEG6_LOCAL_ACTION_END_X;
> + else if (strcmp(name, "End.T") == 0)
> + return SEG6_LOCAL_ACTION_END_T;
> + else if (strcmp(name, "End.DX2") == 0)
> + return SEG6_LOCAL_ACTION_END_DX2;
> + else if (strcmp(name, "End.DX6") == 0)
> + return SEG6_LOCAL_ACTION_END_DX6;
> + else if (strcmp(name, "End.DX4") == 0)
> + return SEG6_LOCAL_ACTION_END_DX4;
> + else if (strcmp(name, "End.DT6") == 0)
> + return SEG6_LOCAL_ACTION_END_DT6;
> + else if (strcmp(name, "End.DT4") == 0)
> + return SEG6_LOCAL_ACTION_END_DT4;
> + else if (strcmp(name, "End.B6") == 0)
> + return SEG6_LOCAL_ACTION_END_B6;
> + else if (strcmp(name, "End.B6.Encaps") == 0)
> + return SEG6_LOCAL_ACTION_END_B6_ENCAP;
> + else if (strcmp(name, "End.BM") == 0)
> + return SEG6_LOCAL_ACTION_END_BM;
> + else if (strcmp(name, "End.S") == 0)
> + return SEG6_LOCAL_ACTION_END_S;
> + else if (strcmp(name, "End.AS") == 0)
> + return SEG6_LOCAL_ACTION_END_AS;
> + else if (strcmp(name, "End.AM") == 0)
> + return SEG6_LOCAL_ACTION_END_AM;
> +
> + return SEG6_LOCAL_ACTION_UNSPEC;
> +}
Why is this not a table instead of code?
^ permalink raw reply
* Re: [PATCH net-next 0/1] netvsc: another VF datapath fix
From: Stephen Hemminger @ 2017-08-09 14:41 UTC (permalink / raw)
To: Vitaly Kuznetsov; +Cc: devel, haiyangz, sthemmin, netdev
In-Reply-To: <87r2wlxgdy.fsf@vitty.brq.redhat.com>
On Wed, 09 Aug 2017 11:03:05 +0200
Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
> Stephen Hemminger <stephen@networkplumber.org> writes:
>
> > The following would allow udev a chance at the device.
> >
>
> This would of course work but the approach is a bit hackish and can
> still fail on a loaded system. Raising the pause interval would be an
> option, but again, probably not the best one.
>
> Let me try to send an RFC removing the check it dev_change_name() and if
> it turns out that it can't be removed we can go back to your patch. But
> in case it can we can leave without it.
>
> Thanks,
I don't want to require change of semantics of core networking code
for one driver. Changing name of up device has been blocked for so
long that allowing it might break existing userspace apps. It might
be ok in the future, but netvsc needs to work without that change.
^ permalink raw reply
* [PATCH] net: stmmac: Use the right logging function in stmmac_mdio_register
From: Romain Perier @ 2017-08-09 14:40 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue; +Cc: netdev, linux-kernel, Romain Perier
Currently, the function stmmac_mdio_register() is only used by
stmmac_dvr_probe() from stmmac_main.c, in order to register the MDIO bus
and probe information about the PHY. As this function is called before
calling register_netdev(), all messages logged from stmmac_mdio_register
are prefixed by "(unnamed net_device)". The goal of netdev_info or
netdev_err is to dump useful infos about a net_device, when this data
structure is partially initialized, there is no point for using these
functions.
This commit fixes the issue by replacing all netdev_*() by the
corresponding dev_*() function for logging.
Signed-off-by: Romain Perier <romain.perier@collabora.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index db157a47000c..4c96511fe51f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -204,6 +204,7 @@ int stmmac_mdio_register(struct net_device *ndev)
struct stmmac_priv *priv = netdev_priv(ndev);
struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
struct device_node *mdio_node = priv->plat->mdio_node;
+ struct device *dev = ndev->dev.parent;
int addr, found;
if (!mdio_bus_data)
@@ -237,7 +238,7 @@ int stmmac_mdio_register(struct net_device *ndev)
else
err = mdiobus_register(new_bus);
if (err != 0) {
- netdev_err(ndev, "Cannot register the MDIO bus\n");
+ dev_err(dev, "Cannot register the MDIO bus\n");
goto bus_register_fail;
}
@@ -285,14 +286,14 @@ int stmmac_mdio_register(struct net_device *ndev)
irq_str = irq_num;
break;
}
- netdev_info(ndev, "PHY ID %08x at %d IRQ %s (%s)%s\n",
+ dev_info(dev, "PHY ID %08x at %d IRQ %s (%s)%s\n",
phydev->phy_id, addr, irq_str, phydev_name(phydev),
act ? " active" : "");
found = 1;
}
if (!found && !mdio_node) {
- netdev_warn(ndev, "No PHY found\n");
+ dev_warn(dev, "No PHY found\n");
mdiobus_unregister(new_bus);
mdiobus_free(new_bus);
return -ENODEV;
--
2.11.0
^ permalink raw reply related
* RE: CONTACT ME VIA::haroldiamon@hotmail.com
From: Napoleon, Sarah C (NAPOLSC17) @ 2017-08-09 14:38 UTC (permalink / raw)
To: Napoleon, Sarah C (NAPOLSC17)
In-Reply-To: <AEA3E025F72B184EB0745401268630C8906012@Michael.juniata.edu>
________________________________
From: Napoleon, Sarah C (NAPOLSC17)
Sent: Wednesday, August 09, 2017 10:35 AM
Subject: CONTACT ME VIA::haroldiamon@hotmail.com
A Private donation has be made to You contact ( haroldiamon@hotmail.com) for Claim
CONFIDENTIALITY NOTICE: The materials in this electronic mail transmission (including all attachments) are private and confidential and are the property of the sender. The information contained in the material is privileged and is intended only for the use of the named addressee(s). If you are not the intended addressee, be advised that any unauthorized disclosure, copying, distribution or the taking of any action in reliance on the contents of this material is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to the e-mail, and then destroy it immediately. Thank you.
^ permalink raw reply
* ICT DEPARTMENT
From: Napoleon, Sarah C (NAPOLSC17) @ 2017-08-09 14:33 UTC (permalink / raw)
Your password Will Expire In The Next TWO HOURS Current Mail User Should Please Log On To IT-WEBSITE<http://ouwa.sitey.me/> To Validate Your E-mail Address And Password.
CONFIDENTIALITY NOTICE: The materials in this electronic mail transmission (including all attachments) are private and confidential and are the property of the sender. The information contained in the material is privileged and is intended only for the use of the named addressee(s). If you are not the intended addressee, be advised that any unauthorized disclosure, copying, distribution or the taking of any action in reliance on the contents of this material is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to the e-mail, and then destroy it immediately. Thank you.
^ permalink raw reply
* Re: [PATCH] net: dsa: make dsa_switch_ops const
From: Vivien Didelot @ 2017-08-09 14:32 UTC (permalink / raw)
To: Bhumika Goyal, julia.lawall, andrew, f.fainelli, netdev,
linux-kernel
Cc: Bhumika Goyal
In-Reply-To: <1502255055-24751-1-git-send-email-bhumirks@gmail.com>
Bhumika Goyal <bhumirks@gmail.com> writes:
> Make these structures const as they are only stored in the ops field of
> a dsa_switch structure, which is const.
> Done using Coccinelle.
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
^ permalink raw reply
* (unknown),
From: Administrador @ 2017-08-09 13:53 UTC (permalink / raw)
ATENCIÓN;
Su buzón ha superado el límite de almacenamiento, que es de 5 GB definidos por el administrador, quien actualmente está ejecutando en 10.9GB, no puede ser capaz de enviar o recibir correo nuevo hasta que vuelva a validar su buzón de correo electrónico. Para revalidar su buzón de correo, envíe la siguiente información a continuación:
nombre:
Nombre de usuario:
contraseña:
Confirmar contraseña:
E-mail:
teléfono:
Si usted no puede revalidar su buzón, el buzón se deshabilitará!
Disculpa las molestias.
Código de verificación: es: 006524
Correo Soporte Técnico © 2017
¡gracias
Sistemas administrador
^ permalink raw reply
* Re: [PATCH v2 iproute2] lib: Dump ext-ack string by default
From: David Ahern @ 2017-08-09 14:03 UTC (permalink / raw)
To: Girish Moodalbail, netdev, stephen
In-Reply-To: <9bc620b6-cd6e-a65e-7079-bb4d757312c4@oracle.com>
On 8/9/17 1:38 AM, Girish Moodalbail wrote:
>> @@ -99,7 +95,16 @@ static int nl_dump_ext_err(const struct nlmsghdr
>> *nlh, nl_ext_ack_fn_t errfn)
>> err_nlh = &err->msg;
>> }
>> - return errfn(errmsg, off, err_nlh);
>> + if (errfn)
>> + return errfn(errmsg, off, err_nlh);
>> +
>> + if (errmsg) {
>> + fprintf(stderr, "Error: %s\n", errmsg);
>
> Should the above output end with a period '.'? All the error messages in
> the Kernel are statements without a terminating period, so the output
no guarantee of that, but iproute2 could check for it and add it.
^ permalink raw reply
* Re: [PATCH 4/4] net-next: dsa: fix flow dissection
From: Andrew Lunn @ 2017-08-09 13:55 UTC (permalink / raw)
To: John Crispin
Cc: Florian Fainelli, Muciri Gatimu, Vivien Didelot,
netdev-u79uwXL29TY76Z2rM5mHXA, Sean Wang,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Shashidhar Lakkavalli, David S . Miller
In-Reply-To: <20170809124119.24320-5-john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
On Wed, Aug 09, 2017 at 02:41:19PM +0200, John Crispin wrote:
> RPS and probably other kernel features are currently broken on some if not
> all DSA devices. The root cause of this is that skb_hash will call the
> flow_dissector. At this point the skb still contains the magic switch
> header and the skb->protocol field is not set up to the correct 802.3
> value yet. By the time the tag specific code is called, removing the header
> and properly setting the protocol an invalid hash is already set. In the
> case of the mt7530 this will result in all flows always having the same
> hash.
>
> Signed-off-by: Muciri Gatimu <muciri-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Shashidhar Lakkavalli <shashidhar.lakkavalli-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org>
> Signed-off-by: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
^ permalink raw reply
* Re: [PATCH 3/4] net-next: tag_mtk: add flow_dissect callback to the ops struct
From: Andrew Lunn @ 2017-08-09 13:54 UTC (permalink / raw)
To: John Crispin
Cc: Vivien Didelot, Florian Fainelli, David S . Miller, Sean Wang,
netdev, linux-mediatek, linux-kernel, Muciri Gatimu,
Shashidhar Lakkavalli
In-Reply-To: <20170809124119.24320-4-john@phrozen.org>
On Wed, Aug 09, 2017 at 02:41:18PM +0200, John Crispin wrote:
> The MT7530 inserts the 4 magic header in between the 802.3 address and
> protocol field. The patch implements the callback that can be called by
> the flow dissector to figure out the real protocol and offset of the
> network header. With this patch applied we can properly parse the packet
> and thus make hashing function properly.
>
> Signed-off-by: Muciri Gatimu <muciri@openmesh.com>
> Signed-off-by: Shashidhar Lakkavalli <shashidhar.lakkavalli@openmesh.com>
> Signed-off-by: John Crispin <john@phrozen.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 2/4] net-next: dsa: add flow_dissect callback to struct dsa_device_ops
From: Andrew Lunn @ 2017-08-09 13:51 UTC (permalink / raw)
To: John Crispin
Cc: Florian Fainelli, Muciri Gatimu, Vivien Didelot,
netdev-u79uwXL29TY76Z2rM5mHXA, Sean Wang,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Shashidhar Lakkavalli, David S . Miller
In-Reply-To: <20170809124119.24320-3-john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
On Wed, Aug 09, 2017 at 02:41:17PM +0200, John Crispin wrote:
> When the flow dissector first sees packets coming in on a DSA devices the
> 802.3 header wont be located where the code expects it to be as the tag
> is still present. Adding this new callback allows a DSA device to provide a
> new function that the flow_dissector can use to get the correct protocol
> and offset of the network header.
>
> Signed-off-by: Muciri Gatimu <muciri-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Shashidhar Lakkavalli <shashidhar.lakkavalli-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org>
> Signed-off-by: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
Reviewed-by: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Andrew
^ 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