* [PATCH iproute2 master 0/2] Two minor BPF updates
From: Daniel Borkmann @ 2017-09-05 0:24 UTC (permalink / raw)
To: stephen; +Cc: ast, netdev, Daniel Borkmann
Two minor updates including a small cleanup for dumping
the trace pipe and one for consolidating prog dumps for
tc and xdp to use bpf_prog_info_by_fd() when possible.
Thanks!
Daniel Borkmann (2):
bpf: minor cleanups for bpf_trace_pipe
bpf: consolidate dumps to use bpf_dump_prog_info
include/bpf_util.h | 2 +-
ip/ipaddress.c | 6 ++++--
ip/iplink_xdp.c | 19 +++++++++++++++----
ip/xdp.h | 2 +-
lib/bpf.c | 31 ++++++++++++++++++-------------
tc/f_bpf.c | 8 ++++----
tc/m_bpf.c | 8 ++++----
7 files changed, 47 insertions(+), 29 deletions(-)
--
1.9.3
^ permalink raw reply
* [PATCH iproute2 master 1/2] bpf: minor cleanups for bpf_trace_pipe
From: Daniel Borkmann @ 2017-09-05 0:24 UTC (permalink / raw)
To: stephen; +Cc: ast, netdev, Daniel Borkmann
In-Reply-To: <cover.1504570627.git.daniel@iogearbox.net>
Just minor nits, e.g. no need to fflush() and instead of returning
right away, just break and close the fd.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
lib/bpf.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/lib/bpf.c b/lib/bpf.c
index 5fd4928..7463fdc 100644
--- a/lib/bpf.c
+++ b/lib/bpf.c
@@ -569,9 +569,9 @@ int bpf_trace_pipe(void)
"/trace",
0,
};
+ int fd_in, fd_out = STDERR_FILENO;
char tpipe[PATH_MAX];
const char *mnt;
- int fd;
mnt = bpf_find_mntpt("tracefs", TRACEFS_MAGIC, tracefs_mnt,
sizeof(tracefs_mnt), tracefs_known_mnts);
@@ -582,8 +582,8 @@ int bpf_trace_pipe(void)
snprintf(tpipe, sizeof(tpipe), "%s/trace_pipe", mnt);
- fd = open(tpipe, O_RDONLY);
- if (fd < 0)
+ fd_in = open(tpipe, O_RDONLY);
+ if (fd_in < 0)
return -1;
fprintf(stderr, "Running! Hang up with ^C!\n\n");
@@ -591,15 +591,14 @@ int bpf_trace_pipe(void)
static char buff[4096];
ssize_t ret;
- ret = read(fd, buff, sizeof(buff) - 1);
- if (ret > 0) {
- if (write(STDERR_FILENO, buff, ret) != ret)
- return -1;
- fflush(stderr);
- }
+ ret = read(fd_in, buff, sizeof(buff));
+ if (ret > 0 && write(fd_out, buff, ret) == ret)
+ continue;
+ break;
}
- return 0;
+ close(fd_in);
+ return -1;
}
static int bpf_gen_global(const char *bpf_sub_dir)
--
1.9.3
^ permalink raw reply related
* [PATCH iproute2 master 2/2] bpf: consolidate dumps to use bpf_dump_prog_info
From: Daniel Borkmann @ 2017-09-05 0:24 UTC (permalink / raw)
To: stephen; +Cc: ast, netdev, Daniel Borkmann
In-Reply-To: <cover.1504570627.git.daniel@iogearbox.net>
Consolidate dump of prog info to use bpf_dump_prog_info() when possible.
Moving forward, we want to have a consistent output for BPF progs when
being dumped. E.g. in cls/act case we used to dump tag as a separate
netlink attribute before we had BPF_OBJ_GET_INFO_BY_FD bpf(2) command.
Move dumping tag into bpf_dump_prog_info() as well, and only dump the
netlink attribute for older kernels. Also, reuse bpf_dump_prog_info()
for XDP case, so we can dump tag and whether program was jited, which
we currently don't show.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
include/bpf_util.h | 2 +-
ip/ipaddress.c | 6 ++++--
ip/iplink_xdp.c | 19 +++++++++++++++----
ip/xdp.h | 2 +-
lib/bpf.c | 12 +++++++++---
tc/f_bpf.c | 8 ++++----
tc/m_bpf.c | 8 ++++----
7 files changed, 38 insertions(+), 19 deletions(-)
diff --git a/include/bpf_util.h b/include/bpf_util.h
index 6582ec8..e818221 100644
--- a/include/bpf_util.h
+++ b/include/bpf_util.h
@@ -261,7 +261,7 @@ int bpf_prog_load(enum bpf_prog_type type, const struct bpf_insn *insns,
int bpf_prog_attach_fd(int prog_fd, int target_fd, enum bpf_attach_type type);
int bpf_prog_detach_fd(int target_fd, enum bpf_attach_type type);
-void bpf_dump_prog_info(FILE *f, uint32_t id);
+int bpf_dump_prog_info(FILE *f, uint32_t id);
#ifdef HAVE_ELF
int bpf_send_map_fds(const char *path, const char *obj);
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index c9312f0..dbdd839 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -837,7 +837,7 @@ int print_linkinfo(const struct sockaddr_nl *who,
if (tb[IFLA_MTU])
fprintf(fp, "mtu %u ", rta_getattr_u32(tb[IFLA_MTU]));
if (tb[IFLA_XDP])
- xdp_dump(fp, tb[IFLA_XDP]);
+ xdp_dump(fp, tb[IFLA_XDP], do_link, false);
if (tb[IFLA_QDISC])
fprintf(fp, "qdisc %s ", rta_getattr_str(tb[IFLA_QDISC]));
if (tb[IFLA_MASTER]) {
@@ -951,12 +951,14 @@ int print_linkinfo(const struct sockaddr_nl *who,
}
}
-
if ((do_link || show_details) && tb[IFLA_IFALIAS]) {
fprintf(fp, "%s alias %s", _SL_,
rta_getattr_str(tb[IFLA_IFALIAS]));
}
+ if ((do_link || show_details) && tb[IFLA_XDP])
+ xdp_dump(fp, tb[IFLA_XDP], true, true);
+
if (do_link && show_stats) {
fprintf(fp, "%s", _SL_);
__print_link_stats(fp, tb);
diff --git a/ip/iplink_xdp.c b/ip/iplink_xdp.c
index 9ae9ee5..5aa66fe 100644
--- a/ip/iplink_xdp.c
+++ b/ip/iplink_xdp.c
@@ -81,9 +81,10 @@ int xdp_parse(int *argc, char ***argv, struct iplink_req *req, bool generic,
return 0;
}
-void xdp_dump(FILE *fp, struct rtattr *xdp)
+void xdp_dump(FILE *fp, struct rtattr *xdp, bool link, bool details)
{
struct rtattr *tb[IFLA_XDP_MAX + 1];
+ __u32 prog_id = 0;
__u8 mode;
parse_rtattr_nested(tb, IFLA_XDP_MAX, xdp);
@@ -94,6 +95,8 @@ void xdp_dump(FILE *fp, struct rtattr *xdp)
mode = rta_getattr_u8(tb[IFLA_XDP_ATTACHED]);
if (mode == XDP_ATTACHED_NONE)
return;
+ else if (details && link)
+ fprintf(fp, "%s prog/xdp", _SL_);
else if (mode == XDP_ATTACHED_DRV)
fprintf(fp, "xdp");
else if (mode == XDP_ATTACHED_SKB)
@@ -104,8 +107,16 @@ void xdp_dump(FILE *fp, struct rtattr *xdp)
fprintf(fp, "xdp[%u]", mode);
if (tb[IFLA_XDP_PROG_ID])
- fprintf(fp, "/id:%u",
- rta_getattr_u32(tb[IFLA_XDP_PROG_ID]));
+ prog_id = rta_getattr_u32(tb[IFLA_XDP_PROG_ID]);
+ if (!details) {
+ if (prog_id && !link)
+ fprintf(fp, "/id:%u", prog_id);
+ fprintf(fp, " ");
+ return;
+ }
- fprintf(fp, " ");
+ if (prog_id) {
+ fprintf(fp, " ");
+ bpf_dump_prog_info(fp, prog_id);
+ }
}
diff --git a/ip/xdp.h b/ip/xdp.h
index ba897a2..1efd591 100644
--- a/ip/xdp.h
+++ b/ip/xdp.h
@@ -5,6 +5,6 @@
int xdp_parse(int *argc, char ***argv, struct iplink_req *req, bool generic,
bool drv, bool offload);
-void xdp_dump(FILE *fp, struct rtattr *tb);
+void xdp_dump(FILE *fp, struct rtattr *tb, bool link, bool details);
#endif /* __XDP__ */
diff --git a/lib/bpf.c b/lib/bpf.c
index 7463fdc..cfa1f79 100644
--- a/lib/bpf.c
+++ b/lib/bpf.c
@@ -179,25 +179,31 @@ static int bpf_prog_info_by_fd(int fd, struct bpf_prog_info *info,
return ret;
}
-void bpf_dump_prog_info(FILE *f, uint32_t id)
+int bpf_dump_prog_info(FILE *f, uint32_t id)
{
struct bpf_prog_info info = {};
uint32_t len = sizeof(info);
- int fd, ret;
+ int fd, ret, dump_ok = 0;
+ SPRINT_BUF(tmp);
fprintf(f, "id %u ", id);
fd = bpf_prog_fd_by_id(id);
if (fd < 0)
- return;
+ return dump_ok;
ret = bpf_prog_info_by_fd(fd, &info, &len);
if (!ret && len) {
+ fprintf(f, "tag %s ",
+ hexstring_n2a(info.tag, sizeof(info.tag),
+ tmp, sizeof(tmp)));
if (info.jited_prog_len)
fprintf(f, "jited ");
+ dump_ok = 1;
}
close(fd);
+ return dump_ok;
}
static int bpf_parse_string(char *arg, bool from_file, __u16 *bpf_len,
diff --git a/tc/f_bpf.c b/tc/f_bpf.c
index 2f8d12a..4fb9209 100644
--- a/tc/f_bpf.c
+++ b/tc/f_bpf.c
@@ -177,6 +177,7 @@ static int bpf_print_opt(struct filter_util *qu, FILE *f,
struct rtattr *opt, __u32 handle)
{
struct rtattr *tb[TCA_BPF_MAX + 1];
+ int dump_ok = 0;
if (opt == NULL)
return 0;
@@ -221,7 +222,9 @@ static int bpf_print_opt(struct filter_util *qu, FILE *f,
bpf_print_ops(f, tb[TCA_BPF_OPS],
rta_getattr_u16(tb[TCA_BPF_OPS_LEN]));
- if (tb[TCA_BPF_TAG]) {
+ if (tb[TCA_BPF_ID])
+ dump_ok = bpf_dump_prog_info(f, rta_getattr_u32(tb[TCA_BPF_ID]));
+ if (!dump_ok && tb[TCA_BPF_TAG]) {
SPRINT_BUF(b);
fprintf(f, "tag %s ",
@@ -230,9 +233,6 @@ static int bpf_print_opt(struct filter_util *qu, FILE *f,
b, sizeof(b)));
}
- if (tb[TCA_BPF_ID])
- bpf_dump_prog_info(f, rta_getattr_u32(tb[TCA_BPF_ID]));
-
if (tb[TCA_BPF_POLICE]) {
fprintf(f, "\n");
tc_print_police(f, tb[TCA_BPF_POLICE]);
diff --git a/tc/m_bpf.c b/tc/m_bpf.c
index df559bc..e3d0a2b 100644
--- a/tc/m_bpf.c
+++ b/tc/m_bpf.c
@@ -154,6 +154,7 @@ static int bpf_print_opt(struct action_util *au, FILE *f, struct rtattr *arg)
{
struct rtattr *tb[TCA_ACT_BPF_MAX + 1];
struct tc_act_bpf *parm;
+ int dump_ok = 0;
if (arg == NULL)
return -1;
@@ -177,7 +178,9 @@ static int bpf_print_opt(struct action_util *au, FILE *f, struct rtattr *arg)
fprintf(f, " ");
}
- if (tb[TCA_ACT_BPF_TAG]) {
+ if (tb[TCA_ACT_BPF_ID])
+ dump_ok = bpf_dump_prog_info(f, rta_getattr_u32(tb[TCA_ACT_BPF_ID]));
+ if (!dump_ok && tb[TCA_ACT_BPF_TAG]) {
SPRINT_BUF(b);
fprintf(f, "tag %s ",
@@ -186,9 +189,6 @@ static int bpf_print_opt(struct action_util *au, FILE *f, struct rtattr *arg)
b, sizeof(b)));
}
- if (tb[TCA_ACT_BPF_ID])
- bpf_dump_prog_info(f, rta_getattr_u32(tb[TCA_ACT_BPF_ID]));
-
print_action_control(f, "default-action ", parm->action, "\n");
fprintf(f, "\tindex %u ref %d bind %d", parm->index, parm->refcnt,
parm->bindcnt);
--
1.9.3
^ permalink raw reply related
* [PATCH] netfilter: xt_hashlimit: fix 64 bit division compile error
From: Vishwanath Pai @ 2017-09-05 1:03 UTC (permalink / raw)
To: pablo, kadlec, netfilter-devel; +Cc: johunt, fw, netdev, pai.vishwain
commit bea74641e378 ("netfilter: xt_hashlimit: add rate match mode")
introduced a line where we divide two 64bit unsigned integers. This
breaks on ARM processors with the error:
ERROR: "__aeabi_uldivmod" [net/netfilter/xt_hashlimit.ko] undefined!
We can fix it by using div64_u64 instead.
Fixes: bea74641e378 ("netfilter: xt_hashlimit: add rate match mode")
Signed-off-by: Vishwanath Pai <vpai@akamai.com>
---
net/netfilter/xt_hashlimit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/xt_hashlimit.c b/net/netfilter/xt_hashlimit.c
index 10d4823..fece7c2 100644
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -531,7 +531,7 @@ static u64 user2rate_bytes(u64 user)
{
u64 r;
- r = user ? 0xFFFFFFFFULL / user : 0xFFFFFFFFULL;
+ r = user ? div64_u64(0xFFFFFFFFULL, user) : 0xFFFFFFFFULL;
r = (r - 1) << 4;
return r;
}
--
1.9.1
^ permalink raw reply related
* [PATCH net V2] vhost_net: correctly check tx avail during rx busy polling
From: Jason Wang @ 2017-09-05 1:22 UTC (permalink / raw)
To: mst, jasowang, netdev; +Cc: kvm, virtualization, linux-kernel
We check tx avail through vhost_enable_notify() in the past which is
wrong since it only checks whether or not guest has filled more
available buffer since last avail idx synchronization which was just
done by vhost_vq_avail_empty() before. What we really want is checking
pending buffers in the avail ring. Fix this by calling
vhost_vq_avail_empty() instead.
This issue could be noticed by doing netperf TCP_RR benchmark as
client from guest (but not host). With this fix, TCP_RR from guest to
localhost restores from 1375.91 trans per sec to 55235.28 trans per
sec on my laptop (Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz).
Fixes: 030881372460 ("vhost_net: basic polling support")
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
- The patch is needed for -stable
- Changes from V1: enable vq notification when needed
---
drivers/vhost/net.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 06d0448..1c75572 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -634,8 +634,13 @@ static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk)
preempt_enable();
- if (vhost_enable_notify(&net->dev, vq))
+ if (!vhost_vq_avail_empty(&net->dev, vq))
vhost_poll_queue(&vq->poll);
+ else if (unlikely(vhost_enable_notify(&net->dev, vq))) {
+ vhost_disable_notify(&net->dev, vq);
+ vhost_poll_queue(&vq->poll);
+ }
+
mutex_unlock(&vq->mutex);
len = peek_head_len(rvq, sk);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/2] netfilter/xt_hashlimit: new feature/algorithm for xt_hashlimit
From: Vishwanath Pai @ 2017-09-05 1:56 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: kadlec, netfilter-devel, johunt, fw, netdev, pai.vishwain
In-Reply-To: <20170904101433.GA3979@salvia>
On 09/04/2017 06:14 AM, Pablo Neira Ayuso wrote:
> Sounds good, applied, thanks.
>
> A couple of questions: Does it really make sense to expose
> --hashlimit-rate-interval or are you using 1 second always there? I
> always wonder if it makes sense to expose yet another toggle that it's
> not clear to me how the user would take advantage from this.
>
> Just curious here.
Thank you Pablo.
I generally just let rate-interval to default to 1, but I've added the
toggle to give the user more control on how often to sample the packet
rate. This wasn't an option before since we would always keep "delta" as
1 jiffy, but that is not the case in the new algorithm. Hence I have
exposed it as an option to the user.
Also, it looks like I broke the build on ARM and m68k arch. This is
because of the u64 division issue (sorry about that). I have sent
another patch to fix the problem "[PATCH] netfilter: xt_hashlimit: fix
64 bit division compile error". Please apply and send to net-next.
Thanks,
Vishwanath
^ permalink raw reply
* Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support
From: Yang, Yi @ 2017-09-05 2:11 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, e@erig.me
In-Reply-To: <87mv6abte5.fsf-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
On Mon, Sep 04, 2017 at 07:22:26PM +0800, Hannes Frederic Sowa wrote:
> Hello,
>
> "Yang, Yi" <yi.y.yang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> writes:
>
> > On Wed, Aug 30, 2017 at 05:53:27PM +0800, Hannes Frederic Sowa wrote:
> >> Hello,
> >>
> >> Yi Yang <yi.y.yang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> writes:
> >>
> >> [...]
> >>
> >> > +struct ovs_key_nsh {
> >> > + u8 flags;
> >> > + u8 ttl;
> >> > + u8 mdtype;
> >> > + u8 np;
> >> > + __be32 path_hdr;
> >> > + __be32 context[NSH_MD1_CONTEXT_SIZE];
> >> > +};
> >> > +
> >> > struct sw_flow_key {
> >> > u8 tun_opts[IP_TUNNEL_OPTS_MAX];
> >> > u8 tun_opts_len;
> >> > @@ -144,6 +154,7 @@ struct sw_flow_key {
> >> > };
> >> > } ipv6;
> >> > };
> >> > + struct ovs_key_nsh nsh; /* network service header */
> >> > struct {
> >> > /* Connection tracking fields not packed above. */
> >> > struct {
> >>
> >> Does it makes sense to keep the context headers as part of the flow?
> >> What is the reasoning behind it? With mdtype 2 headers this might either
> >> not work very well or will increase sw_flow_key size causing slowdowns
> >> for all protocols.
> >
> > For userspace, miniflow can handle such issue, but kernel data path
> > didn't provide such mechanism, so I don't think we can think of a better
> > way to fix this.
>
> I do think that both, kernel and dpdk dp, are fine if you don't match on
> context fields, which I think is the common case.
>
> As soon as a few paths start to match on contexts at different offsets I
> am not sure if miniflow will actually help. I don't know enough about
> that. Set cover is a NP hard problem, so constructing plain simple flows
> will be an approximation somewhere anyway at some point.
>
> If the context values are in some way discrete it might make sense, but
> for load balancing purposes your ingress router might fill out one
> context field with a flow hash of the inner flow to allow ECMP or
> loadbalancing. You might want to treat that separately. Otherwise the
> different paths might always need to context[3] & 0x3 (bits as number of
> possible next hops) and put that into the flow state. Because every hop
> and every path might have different numbers of nexthops etc., I don't
> think this is easy unifiable anymore.
Anyway, this is a common issue but not NSH-implemention-specific issue.
In my perspective, kernel data path won't have better perfromance than
userspace DPDK data path, maybe you're considering hardware offload, but
so far there isn't an infrastructure in OVS to offload NSH.
>
> > We have to have context headers in flow for match and set, every hop in
> > service function chaining can put its metedata into context headers on
> > demand, MD type 2 is much more complicated than you can imagine, it is
> > impossible to use an uniform way to handle MD type 1 and MD type 2, our
> > way is to keep MD type 1 keys in struct ovs_key_nsh and to reuse struct
> > flow_tnl for MD type 2 metadata, in case of MD type 2, we can set
> > context headers to 0 in struct ovs_key_nsh.
>
> Understood and agreed.
>
> > I beleive every newly-added key will result in similiar issue you
> > concern, maybe it will be better to introduce miniflow in kernel data
> > path, but it isn't in scope of this patch series.
>
> You will see the same problem with offloading flows e.g. to network
> cards very soon. Flow explosion here will cause your 100Gbit/s NIC
> suddenly to go to software slow path.
Do you mean the whole OVS data path offload? As I said, this is a common
issue, it isn't NSH-specific.
>
> > It will be great if you can have a better proposal to fix your concern.
>
> I do think that something alike miniflow might make sense, but I don't
> know enough about miniflow.
>
> New ACTIONS, that are not only bound to NSH, seem appealing to me at the
> moment. E.g. have a subtable match in the kernel dp or allowing for some
> OXM % modulo -> select action or neighbor alike thing would probably
> cover a lot of cases in the beginning. The submatch would probably very
> much reassemble the miniflow in dpdk dp.
I'm not sure what new action you expect to bring here, I think group
action is just for this, as you said it isn't only bound to NSH, you can
start a new thread to discuss this. I don't think it is in scope of NSH.
>
> Thanks,
> Hannes
^ permalink raw reply
* Re: Fwd: DA850-evm MAC Address is random
From: Sekhar Nori @ 2017-09-05 4:42 UTC (permalink / raw)
To: Adam Ford; +Cc: Tony Lindgren, Grygorii Strashko, linux-omap, netdev
In-Reply-To: <ffec81da-78b6-7f1a-e477-ab0a9d2e4f37@ti.com>
Hi Adam,
On Wednesday 30 August 2017 11:08 AM, Sekhar Nori wrote:
>> I wonder if U-Boot isn't pushing something to Linux because it doesn't
>> appear to be running some of the da850 specific code even when I run
>> linux-next. Can you tell me what verision of U-Boot you're using?
>> Other than using davinci_all_defconfig, did you change the
>> configuration at all?
> I am using U-Boot 2017.01. Yes, the kernel was built using
> davinci_all_defconfig and no other config change. Before booting kernel,
> can you confirm that ethaddr is set in U-Boot environment? This is what
> fdt_fixup_ethernet() reads to fixup the FDT before boot.
>
> Here is my complete boot log with environment variable dump.
>
> http://pastebin.ubuntu.com/25430265/
Were you able to get rid of the random mac address problem?
Thanks,
Sekhar
^ permalink raw reply
* linux-next: manual merge of the akpm-current tree with the net-next tree
From: Stephen Rothwell @ 2017-09-05 5:27 UTC (permalink / raw)
To: Andrew Morton, David Miller, Networking
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Varsha Rao,
Pablo Neira Ayuso, Krzysztof Kozlowski
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/sh/configs/se7751_defconfig
between commit:
9efdb14f76f4 ("net: Remove CONFIG_NETFILTER_DEBUG and _ASSERT() macros.")
from the net-next tree and commit:
a83883ff2285 ("sh: defconfig: cleanup from old Kconfig options")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/sh/configs/se7751_defconfig
index 56b5e4ce8d4a,153e1d3c8be5..000000000000
--- a/arch/sh/configs/se7751_defconfig
+++ b/arch/sh/configs/se7751_defconfig
@@@ -25,12 -24,10 +24,9 @@@ CONFIG_IP_PNP=
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
- # CONFIG_INET_LRO is not set
# CONFIG_IPV6 is not set
CONFIG_NETFILTER=y
- CONFIG_IP_NF_QUEUE=y
-CONFIG_NETFILTER_DEBUG=y
CONFIG_MTD=y
- CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_AMDSTD=y
^ permalink raw reply
* [PATCH net-next] bpf: fix numa_node validation
From: Eric Dumazet @ 2017-09-05 5:41 UTC (permalink / raw)
To: David Miller
Cc: netdev, Martin KaFai Lau, Daniel Borkmann, Alexei Starovoitov
From: Eric Dumazet <edumazet@google.com>
syzkaller reported crashes in bpf map creation or map update [1]
Problem is that nr_node_ids is a signed integer,
NUMA_NO_NODE is also an integer, so it is very tempting
to declare numa_node as a signed integer.
This means the typical test to validate a user provided value :
if (numa_node != NUMA_NO_NODE &&
(numa_node >= nr_node_ids ||
!node_online(numa_node)))
must be written :
if (numa_node != NUMA_NO_NODE &&
((unsigned int)numa_node >= nr_node_ids ||
!node_online(numa_node)))
[1]
kernel BUG at mm/slab.c:3256!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 2946 Comm: syzkaller916108 Not tainted 4.13.0-rc7+ #35
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
task: ffff8801d2bc60c0 task.stack: ffff8801c0c90000
RIP: 0010:____cache_alloc_node+0x1d4/0x1e0 mm/slab.c:3292
RSP: 0018:ffff8801c0c97638 EFLAGS: 00010096
RAX: ffffffffffff8b7b RBX: 0000000001080220 RCX: 0000000000000000
RDX: 00000000ffff8b7b RSI: 0000000001080220 RDI: ffff8801dac00040
RBP: ffff8801c0c976c0 R08: 0000000000000000 R09: 0000000000000000
R10: ffff8801c0c97620 R11: 0000000000000001 R12: ffff8801dac00040
R13: ffff8801dac00040 R14: 0000000000000000 R15: 00000000ffff8b7b
FS: 0000000002119940(0000) GS:ffff8801db200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020001fec CR3: 00000001d2980000 CR4: 00000000001406f0
Call Trace:
__do_kmalloc_node mm/slab.c:3688 [inline]
__kmalloc_node+0x33/0x70 mm/slab.c:3696
kmalloc_node include/linux/slab.h:535 [inline]
alloc_htab_elem+0x2a8/0x480 kernel/bpf/hashtab.c:740
htab_map_update_elem+0x740/0xb80 kernel/bpf/hashtab.c:820
map_update_elem kernel/bpf/syscall.c:587 [inline]
SYSC_bpf kernel/bpf/syscall.c:1468 [inline]
SyS_bpf+0x20c5/0x4c40 kernel/bpf/syscall.c:1443
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x440409
RSP: 002b:00007ffd1f1792b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440409
RDX: 0000000000000020 RSI: 0000000020006000 RDI: 0000000000000002
RBP: 0000000000000086 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401d70
R13: 0000000000401e00 R14: 0000000000000000 R15: 0000000000000000
Code: 83 c2 01 89 50 18 4c 03 70 08 e8 38 f4 ff ff 4d 85 f6 0f 85 3e ff ff ff 44 89 fe 4c 89 ef e8 94 fb ff ff 49 89 c6 e9 2b ff ff ff <0f> 0b 0f 0b 0f 0b 66 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41
RIP: ____cache_alloc_node+0x1d4/0x1e0 mm/slab.c:3292 RSP: ffff8801c0c97638
---[ end trace d745f355da2e33ce ]---
Kernel panic - not syncing: Fatal exception
Fixes: 96eabe7a40aa ("bpf: Allow selecting numa node during map creation")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Alexei Starovoitov <ast@fb.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
---
kernel/bpf/syscall.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 021a05d9d80095303bdfed51ee85bd9067582774..70ad8e220343c7825c8e331f19c1f65c78fdb796 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -323,7 +323,8 @@ static int map_create(union bpf_attr *attr)
return -EINVAL;
if (numa_node != NUMA_NO_NODE &&
- (numa_node >= nr_node_ids || !node_online(numa_node)))
+ ((unsigned int)numa_node >= nr_node_ids ||
+ !node_online(numa_node)))
return -EINVAL;
/* find map type and init map: hashtable vs rbtree vs bloom vs ... */
^ permalink raw reply related
* Re: [PATCH net-next v7] openvswitch: enable NSH support
From: Yang, Yi @ 2017-09-05 5:51 UTC (permalink / raw)
To: Jiri Benc
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, e@erig.me,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <20170904145744.4d8b7fd5@griffin>
On Mon, Sep 04, 2017 at 08:57:44PM +0800, Jiri Benc wrote:
> On Mon, 4 Sep 2017 20:09:07 +0800, Yang, Yi wrote:
> > So we must do many changes if we want to break this assumption.
>
> We may do as many changes as we want to. This is uAPI we're talking
> about and we need to get it right since the beginning. Sure, it may
> mean that some user space programs need some changes in order to make
> use of the new features. That happens every day.
>
> I also don't understand where's the problem. It's very easy to check
> for NLA_F_NESTED and generically act based on that in the function you
> quoted. Just call a different function than format_odp_key_attr to
> handle ovs_nsh_key_attr attributes in case the nested flag is set and
> the attribute is OVS_KEY_ATTR_NSH and you're done. You'll need such
> function anyway, it's not much different code size wise to call it from
> format_odp_key_attr or from format_odp_action.
But if we follow your way, how does nla_for_each_nested handle such
pattern?
attribute1
attribute1_mask
attribute2
attribute2_mask
attribute3
attribute3_mask
I don't think this can increase performance and readability.
In current way, we just call nla_for_each_nested twice
one is for
attribute1
attribute2
attribute3
another is for
attribute1_mask
attribute2_mask
attribute3_mask
if we use one function to handle both attributes and masks, I can't
see any substantial difference between two ways as far as the
performance is concerned.
So my proposal is we needn't introduce special handling case for
OVS_KEY_ATTR_NSH in OVS_ACTION_ATTR_SET_MASKED, that will open Pandora's
box.
If we consider OVS_KEY_ATTR_NSH as a big attribute, current way is
precisely following current design pattern
attribute
mask
>
> Jiri
^ permalink raw reply
* Re: [PATCH net-next v7] openvswitch: enable NSH support
From: Yang, Yi @ 2017-09-05 6:37 UTC (permalink / raw)
To: Jiri Benc
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, e@erig.me,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <20170904124216.6db68e8c@griffin>
On Mon, Sep 04, 2017 at 06:42:16PM +0800, Jiri Benc wrote:
> On Mon, 4 Sep 2017 16:00:05 +0800, Yang, Yi wrote:
> > how can we know next push_nsh uses the same nsh header as previous
> > one?
>
> We store the prepopulated header together with the action.
>
I checked source code but can't find where we can prepopulate it and how
we can deliver the prepopulated header to push_nsh, can you expand it in
order that I can know how to do this in code level?
^ permalink raw reply
* Re: [PATCH] geneve: Fix setting ttl value in collect metadata mode
From: Pravin Shelar @ 2017-09-05 6:47 UTC (permalink / raw)
To: Haishuang Yan
Cc: David S. Miller, Girish Moodalbail,
Linux Kernel Network Developers, linux-kernel
In-Reply-To: <1504442982-12431-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
On Sun, Sep 3, 2017 at 5:49 AM, Haishuang Yan
<yanhaishuang@cmss.chinamobile.com> wrote:
> If key->tos is zero in collect metadata mode, tos should fallback to
> ip{4,6}_dst_hoplimit, same as normal mode.
>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
> ---
> drivers/net/geneve.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
> index f640407..d52a65f 100644
> --- a/drivers/net/geneve.c
> +++ b/drivers/net/geneve.c
> @@ -834,11 +834,10 @@ static int geneve_xmit_skb(struct sk_buff *skb, struct net_device *dev,
> sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
> if (geneve->collect_md) {
> tos = ip_tunnel_ecn_encap(key->tos, ip_hdr(skb), skb);
> - ttl = key->ttl;
> } else {
> tos = ip_tunnel_ecn_encap(fl4.flowi4_tos, ip_hdr(skb), skb);
> - ttl = key->ttl ? : ip4_dst_hoplimit(&rt->dst);
> }
> + ttl = key->ttl ? : ip4_dst_hoplimit(&rt->dst);
In collect md mode, geneve has to set TTL value from tunnel metadata.
That is the API exposed to userspace. is there reason for this change?
> df = key->tun_flags & TUNNEL_DONT_FRAGMENT ? htons(IP_DF) : 0;
>
> err = geneve_build_skb(&rt->dst, skb, info, xnet, sizeof(struct iphdr));
> @@ -873,12 +872,11 @@ static int geneve6_xmit_skb(struct sk_buff *skb, struct net_device *dev,
> sport = udp_flow_src_port(geneve->net, skb, 1, USHRT_MAX, true);
> if (geneve->collect_md) {
> prio = ip_tunnel_ecn_encap(key->tos, ip_hdr(skb), skb);
> - ttl = key->ttl;
> } else {
> prio = ip_tunnel_ecn_encap(ip6_tclass(fl6.flowlabel),
> ip_hdr(skb), skb);
> - ttl = key->ttl ? : ip6_dst_hoplimit(dst);
> }
> + ttl = key->ttl ? : ip6_dst_hoplimit(dst);
> err = geneve_build_skb(dst, skb, info, xnet, sizeof(struct ipv6hdr));
> if (unlikely(err))
> return err;
> --
> 1.8.3.1
>
>
>
^ permalink raw reply
* Re: 915f3e3f76 ("mac80211_hwsim: Replace bogus hrtimer clockid"): BUG: kernel reboot-without-warning in test stage
From: Thomas Gleixner @ 2017-09-05 7:12 UTC (permalink / raw)
To: kernel test robot; +Cc: LKP, linux-kernel, netdev, linux-wireless, wfg
In-Reply-To: <59ade247.WzhbxWeytBOa6Xu4%fengguang.wu@intel.com>
On Tue, 5 Sep 2017, kernel test robot wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> commit 915f3e3f76c05b2da93c4cc278eebc2d9219d9f4
> Author: Thomas Gleixner <tglx@linutronix.de>
> AuthorDate: Sat Feb 25 11:27:37 2017 +0100
> Commit: Linus Torvalds <torvalds@linux-foundation.org>
> CommitDate: Sat Feb 25 09:48:16 2017 -0800
>
> mac80211_hwsim: Replace bogus hrtimer clockid
>
> mac80211_hwsim initializes a hrtimer with clockid CLOCK_MONOTONIC_RAW.
> That's not supported.
>
> Use CLOCK_MONOTNIC instead.
Sorry, no. That bisect is completely bogus. The commit in question merily
replaces the unsupported clockid with a valid one.
Thanks,
tglx
^ permalink raw reply
* Re: [RFC net-next 0/5] TSN: Add qdisc-based config interfaces for traffic shapers
From: Richard Cochran @ 2017-09-05 7:20 UTC (permalink / raw)
To: Jesus Sanchez-Palencia
Cc: Vinicius Costa Gomes, netdev, jhs, xiyou.wangcong, jiri,
intel-wired-lan, andre.guedes, ivan.briano, boon.leong.ong
In-Reply-To: <1519366e-5418-4dda-db00-5bf50a1c67c4@intel.com>
On Fri, Sep 01, 2017 at 09:12:17AM -0700, Jesus Sanchez-Palencia wrote:
> On 09/01/2017 06:03 AM, Richard Cochran wrote:
> > The timing of this RFC is good, as I am just finishing up an RFC that
> > implements time-based transmit using the i210. I'll try and get that
> > out ASAP.
I have an RFC series ready for net-next, but the the merge window just
started. I'll post it when the window closes again...
Thanks,
Richard
^ permalink raw reply
* [PATCH] net/ncsi: fix ncsi_vlan_rx_{add,kill}_vid references
From: Arnd Bergmann @ 2017-09-05 8:05 UTC (permalink / raw)
To: David S. Miller, Gavin Shan, Samuel Mendoza-Jonas
Cc: Arnd Bergmann, Joel Stanley, netdev, linux-kernel
We get a new link error in allmodconfig kernels after ftgmac100
started using the ncsi helpers:
ERROR: "ncsi_vlan_rx_kill_vid" [drivers/net/ethernet/faraday/ftgmac100.ko] undefined!
ERROR: "ncsi_vlan_rx_add_vid" [drivers/net/ethernet/faraday/ftgmac100.ko] undefined!
Related to that, we get another error when CONFIG_NET_NCSI is disabled:
drivers/net/ethernet/faraday/ftgmac100.c:1626:25: error: 'ncsi_vlan_rx_add_vid' undeclared here (not in a function); did you mean 'ncsi_start_dev'?
drivers/net/ethernet/faraday/ftgmac100.c:1627:26: error: 'ncsi_vlan_rx_kill_vid' undeclared here (not in a function); did you mean 'ncsi_vlan_rx_add_vid'?
This fixes both problems at once, using a 'static inline' stub helper
for the disabled case, and exporting the functions when they are present.
Fixes: 51564585d8c6 ("ftgmac100: Support NCSI VLAN filtering when available")
Fixes: 21acf63013ed ("net/ncsi: Configure VLAN tag filter")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
include/net/ncsi.h | 10 ++++++++++
net/ncsi/ncsi-manage.c | 2 ++
2 files changed, 12 insertions(+)
diff --git a/include/net/ncsi.h b/include/net/ncsi.h
index 1f96af46df49..fdc60ff2511d 100644
--- a/include/net/ncsi.h
+++ b/include/net/ncsi.h
@@ -36,6 +36,16 @@ int ncsi_start_dev(struct ncsi_dev *nd);
void ncsi_stop_dev(struct ncsi_dev *nd);
void ncsi_unregister_dev(struct ncsi_dev *nd);
#else /* !CONFIG_NET_NCSI */
+static inline int ncsi_vlan_rx_add_vid(struct net_device *dev, __be16 proto, u16 vid)
+{
+ return -EINVAL;
+}
+
+static inline int ncsi_vlan_rx_kill_vid(struct net_device *dev, __be16 proto, u16 vid)
+{
+ return -EINVAL;
+}
+
static inline struct ncsi_dev *ncsi_register_dev(struct net_device *dev,
void (*notifier)(struct ncsi_dev *nd))
{
diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c
index 11904b3b702d..3fd3c39e6278 100644
--- a/net/ncsi/ncsi-manage.c
+++ b/net/ncsi/ncsi-manage.c
@@ -1453,6 +1453,7 @@ int ncsi_vlan_rx_add_vid(struct net_device *dev, __be16 proto, u16 vid)
return found ? ncsi_process_next_channel(ndp) : 0;
}
+EXPORT_SYMBOL_GPL(ncsi_vlan_rx_add_vid);
int ncsi_vlan_rx_kill_vid(struct net_device *dev, __be16 proto, u16 vid)
{
@@ -1491,6 +1492,7 @@ int ncsi_vlan_rx_kill_vid(struct net_device *dev, __be16 proto, u16 vid)
return found ? ncsi_process_next_channel(ndp) : 0;
}
+EXPORT_SYMBOL_GPL(ncsi_vlan_rx_kill_vid);
struct ncsi_dev *ncsi_register_dev(struct net_device *dev,
void (*handler)(struct ncsi_dev *ndev))
--
2.9.0
^ permalink raw reply related
* Re: [PATCH net-next] bpf: fix numa_node validation
From: Daniel Borkmann @ 2017-09-05 8:14 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: netdev, Martin KaFai Lau, Alexei Starovoitov
In-Reply-To: <1504590062.15310.36.camel@edumazet-glaptop3.roam.corp.google.com>
On 09/05/2017 07:41 AM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> syzkaller reported crashes in bpf map creation or map update [1]
>
> Problem is that nr_node_ids is a signed integer,
> NUMA_NO_NODE is also an integer, so it is very tempting
> to declare numa_node as a signed integer.
>
> This means the typical test to validate a user provided value :
>
> if (numa_node != NUMA_NO_NODE &&
> (numa_node >= nr_node_ids ||
> !node_online(numa_node)))
>
> must be written :
>
> if (numa_node != NUMA_NO_NODE &&
> ((unsigned int)numa_node >= nr_node_ids ||
> !node_online(numa_node)))
>
>
> [1]
> kernel BUG at mm/slab.c:3256!
> invalid opcode: 0000 [#1] SMP KASAN
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 2946 Comm: syzkaller916108 Not tainted 4.13.0-rc7+ #35
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> task: ffff8801d2bc60c0 task.stack: ffff8801c0c90000
> RIP: 0010:____cache_alloc_node+0x1d4/0x1e0 mm/slab.c:3292
> RSP: 0018:ffff8801c0c97638 EFLAGS: 00010096
> RAX: ffffffffffff8b7b RBX: 0000000001080220 RCX: 0000000000000000
> RDX: 00000000ffff8b7b RSI: 0000000001080220 RDI: ffff8801dac00040
> RBP: ffff8801c0c976c0 R08: 0000000000000000 R09: 0000000000000000
> R10: ffff8801c0c97620 R11: 0000000000000001 R12: ffff8801dac00040
> R13: ffff8801dac00040 R14: 0000000000000000 R15: 00000000ffff8b7b
> FS: 0000000002119940(0000) GS:ffff8801db200000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000020001fec CR3: 00000001d2980000 CR4: 00000000001406f0
> Call Trace:
> __do_kmalloc_node mm/slab.c:3688 [inline]
> __kmalloc_node+0x33/0x70 mm/slab.c:3696
> kmalloc_node include/linux/slab.h:535 [inline]
> alloc_htab_elem+0x2a8/0x480 kernel/bpf/hashtab.c:740
> htab_map_update_elem+0x740/0xb80 kernel/bpf/hashtab.c:820
> map_update_elem kernel/bpf/syscall.c:587 [inline]
> SYSC_bpf kernel/bpf/syscall.c:1468 [inline]
> SyS_bpf+0x20c5/0x4c40 kernel/bpf/syscall.c:1443
> entry_SYSCALL_64_fastpath+0x1f/0xbe
> RIP: 0033:0x440409
> RSP: 002b:00007ffd1f1792b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440409
> RDX: 0000000000000020 RSI: 0000000020006000 RDI: 0000000000000002
> RBP: 0000000000000086 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401d70
> R13: 0000000000401e00 R14: 0000000000000000 R15: 0000000000000000
> Code: 83 c2 01 89 50 18 4c 03 70 08 e8 38 f4 ff ff 4d 85 f6 0f 85 3e ff ff ff 44 89 fe 4c 89 ef e8 94 fb ff ff 49 89 c6 e9 2b ff ff ff <0f> 0b 0f 0b 0f 0b 66 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41
> RIP: ____cache_alloc_node+0x1d4/0x1e0 mm/slab.c:3292 RSP: ffff8801c0c97638
> ---[ end trace d745f355da2e33ce ]---
> Kernel panic - not syncing: Fatal exception
>
> Fixes: 96eabe7a40aa ("bpf: Allow selecting numa node during map creation")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Cc: Alexei Starovoitov <ast@fb.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
Yeah, thanks for catching this, Eric!
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
^ permalink raw reply
* [PATCH] soc: ti/knav_dma: include dmaengine header
From: Arnd Bergmann @ 2017-09-05 8:31 UTC (permalink / raw)
To: arm, David S. Miller
Cc: Dave Jiang, netdev, Arnd Bergmann, Karicheri, Muralidharan,
linux-kernel
A header file cleanup apparently caused a build regression
with one driver using the knav infrastructure:
In file included from drivers/net/ethernet/ti/netcp_core.c:30:0:
include/linux/soc/ti/knav_dma.h:129:30: error: field 'direction' has incomplete type
enum dma_transfer_direction direction;
^~~~~~~~~
drivers/net/ethernet/ti/netcp_core.c: In function 'netcp_txpipe_open':
drivers/net/ethernet/ti/netcp_core.c:1349:21: error: 'DMA_MEM_TO_DEV' undeclared (first use in this function); did you mean 'DMA_MEMORY_MAP'?
config.direction = DMA_MEM_TO_DEV;
^~~~~~~~~~~~~~
DMA_MEMORY_MAP
drivers/net/ethernet/ti/netcp_core.c:1349:21: note: each undeclared identifier is reported only once for each function it appears in
drivers/net/ethernet/ti/netcp_core.c: In function 'netcp_setup_navigator_resources':
drivers/net/ethernet/ti/netcp_core.c:1659:22: error: 'DMA_DEV_TO_MEM' undeclared (first use in this function); did you mean 'DMA_DESC_HOST'?
config.direction = DMA_DEV_TO_MEM;
As the header is no longer included implicitly through netdevice.h,
we should include it in the header that references the enum.
Fixes: 0dd5759dbb1c ("net: remove dmaengine.h inclusion from netdevice.h")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
If the cleanup patch hasn't been submitted for mainline yet, please
add this fixup to the net-next tree, otherwise I'll merge it through
arm-soc.
---
include/linux/soc/ti/knav_dma.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/soc/ti/knav_dma.h b/include/linux/soc/ti/knav_dma.h
index 2b7882666ef6..66693bc4c6ad 100644
--- a/include/linux/soc/ti/knav_dma.h
+++ b/include/linux/soc/ti/knav_dma.h
@@ -17,6 +17,8 @@
#ifndef __SOC_TI_KEYSTONE_NAVIGATOR_DMA_H__
#define __SOC_TI_KEYSTONE_NAVIGATOR_DMA_H__
+#include <linux/dmaengine.h>
+
/*
* PKTDMA descriptor manipulation macros for host packet descriptor
*/
--
2.9.0
^ permalink raw reply related
* [PATCH net] ip6_gre: update mtu properly in ip6gre_err
From: Xin Long @ 2017-09-05 9:26 UTC (permalink / raw)
To: network dev; +Cc: davem
Now when probessing ICMPV6_PKT_TOOBIG, ip6gre_err only subtracts the
offset of gre header from mtu info. The expected mtu of gre device
should also subtract gre header. Otherwise, the next packets still
can't be sent out.
Jianlin found this issue when using the topo:
client(ip6gre)<---->(nic1)route(nic2)<----->(ip6gre)server
and reducing nic2's mtu, then both tcp and sctp's performance with
big size data became 0.
This patch is to fix it by also subtracting grehdr (tun->tun_hlen)
from mtu info when updating gre device's mtu in ip6gre_err(). It
also needs to subtract ETH_HLEN if gre dev'type is ARPHRD_ETHER.
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/ipv6/ip6_gre.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 67ff2aa..b7a72d4 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -432,7 +432,9 @@ static void ip6gre_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
}
break;
case ICMPV6_PKT_TOOBIG:
- mtu = be32_to_cpu(info) - offset;
+ mtu = be32_to_cpu(info) - offset - t->tun_hlen;
+ if (t->dev->type == ARPHRD_ETHER)
+ mtu -= ETH_HLEN;
if (mtu < IPV6_MIN_MTU)
mtu = IPV6_MIN_MTU;
t->dev->mtu = mtu;
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net-next v7] openvswitch: enable NSH support
From: Jiri Benc @ 2017-09-05 9:46 UTC (permalink / raw)
To: Yang, Yi
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, e@erig.me,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <20170905055144.GA88800-re2EX8HDrk21gSHoDXDV2kEOCMrvLtNR@public.gmane.org>
On Tue, 5 Sep 2017 13:51:45 +0800, Yang, Yi wrote:
> But if we follow your way, how does nla_for_each_nested handle such
> pattern?
>
> attribute1
> attribute1_mask
> attribute2
> attribute2_mask
> attribute3
> attribute3_mask
Uh? That will just work. Note that nla len contains the size of the
whole attribute, i.e. includes both fields.
> I don't think this can increase performance and readability.
Do you realize you're stating that not copying data around in hot path
can't increase performance? ;-)
> if we use one function to handle both attributes and masks, I can't
> see any substantial difference between two ways as far as the
> performance is concerned.
Except that what you did is so unexpected to netlink that you had to go
out of your way to parse it. Those two memcpys speak for themselves.
> If we consider OVS_KEY_ATTR_NSH as a big attribute, current way is
> precisely following current design pattern
Do you have an idea how nested netlink attributes work? It's very well
defined. What you're doing is breaking the definition. You can't do
that.
The (non-nested) attributes contain header followed by data. The data
is a single value or it is a struct. In ovs for masked actions,
attributes contain a struct of two fields (value and mask). The struct
access is open coded but it's still a struct.
Now, nested attributes are very well defined: it's a nla header
followed by a stream of attributes. There's no requirement on the order
of the attributes. Do you see how you're breaking this assumption? You
expect that each attribute is present exactly twice, once among first
half of attributes, once among second half of attributes. You don't
check that this weird assumption is adhered to. You don't even check
that the point where you split the data is between attributes! You may
very well be splitting an attribute in half and interpreting its data
as nla headers.
Consider your proposal NACKed from my side.
Jiri
^ permalink raw reply
* Re: [PATCH net-next v7] openvswitch: enable NSH support
From: Jiri Benc @ 2017-09-05 9:47 UTC (permalink / raw)
To: Yang, Yi
Cc: netdev@vger.kernel.org, davem@davemloft.net, dev@openvswitch.org,
e@erig.me, blp@ovn.org, jan.scheurich@ericsson.com
In-Reply-To: <20170905063705.GA89551@cran64.bj.intel.com>
On Tue, 5 Sep 2017 14:37:05 +0800, Yang, Yi wrote:
> I checked source code but can't find where we can prepopulate it and how
> we can deliver the prepopulated header to push_nsh, can you expand it in
> order that I can know how to do this in code level?
I already said that it's not implemented yet and can be done as a
future performance enhancement.
Jiri
^ permalink raw reply
* Re: [PATCH net-next v7] openvswitch: enable NSH support
From: Jiri Benc @ 2017-09-05 9:49 UTC (permalink / raw)
To: Jan Scheurich
Cc: Yang, Yi, netdev@vger.kernel.org, davem@davemloft.net,
dev@openvswitch.org, e@erig.me, blp@ovn.org
In-Reply-To: <CFF8EF42F1132E4CBE2BF0AB6C21C58D787F4F69@ESESSMB107.ericsson.se>
On Mon, 4 Sep 2017 14:45:50 +0000, Jan Scheurich wrote:
> So what is the correct layout for MASKED_SET action with nested fields?
> 1. All nested values, followed by all nested masks, or
> 2. For each nested field value followed by mask?
>
> I guess alternative 1, but just to be sure.
It's 2. Alternative 1 breaks netlink assumptions, is ugly to implement
and probably impossible to be properly validated.
Jiri
^ permalink raw reply
* Re: [PATCH net-next v6 3/3] openvswitch: enable NSH support
From: Hannes Frederic Sowa @ 2017-09-05 10:30 UTC (permalink / raw)
To: Yang, Yi
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, e@erig.me
In-Reply-To: <20170905021112.GA86057-re2EX8HDrk21gSHoDXDV2kEOCMrvLtNR@public.gmane.org>
"Yang, Yi" <yi.y.yang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> writes:
> I'm not sure what new action you expect to bring here, I think group
> action is just for this, as you said it isn't only bound to NSH, you can
> start a new thread to discuss this. I don't think it is in scope of NSH.
It is in scope of this discussion as you will provide a user space API
that makes the NSH context fields accessible from user space in a
certain way. If you commit to this, there is no way going back.
I haven't yet grasped the idea on how those fields will be used in OVS
besides load balancing. Even for load balancing the tunnel itself
(vxlan-gpe + UDP source port or ipv6 flowlabel) already provides enough
entropy to do per-flow load balancing. What else is needed? Why a
context header for that? You just need multiple action chains and pick
one randomly.
The only protocol that I can compare that to is geneve with TLVs, but
the TLVs are global and uniquie and a property of the networking
forwarding backplane and not a property of the path inside a tenant. So
I expect this actually to be the first case where I think that matters.
Why are context labels that special that they are not part of tun_ops?
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net-next v7] openvswitch: enable NSH support
From: Jan Scheurich @ 2017-09-05 10:36 UTC (permalink / raw)
To: Jiri Benc
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, e@erig.me,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <20170905114949.5849b75f@griffin>
> From: Jiri Benc [mailto:jbenc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org]
> > So what is the correct layout for MASKED_SET action with nested fields?
> > 1. All nested values, followed by all nested masks, or
> > 2. For each nested field value followed by mask?
> >
> > I guess alternative 1, but just to be sure.
>
> It's 2. Alternative 1 breaks netlink assumptions, is ugly to implement
> and probably impossible to be properly validated.
OK. For outsiders this was far from obvious :-)
So, for OVS_ACTION_ATTR_SET_MASKED any nested attribute, no matter on which nesting level, must contain value directly followed by mask.
If that is the principle of handling masks in Netlink APIs, than we must adhere to it.
BR, Jan
^ permalink raw reply
* [PATCH net] net: sched: don't use GFP_KERNEL under spin lock
From: Jakub Kicinski @ 2017-09-05 10:54 UTC (permalink / raw)
To: netdev; +Cc: jiri, Chris Mi, xiyou.wangcong, jhs, oss-drivers, Jakub Kicinski
The new TC IDR code uses GFP_KERNEL under spinlocks. Which leads
to:
[ 582.621091] BUG: sleeping function called from invalid context at ../mm/slab.h:416
[ 582.629721] in_atomic(): 1, irqs_disabled(): 0, pid: 3379, name: tc
[ 582.636939] 2 locks held by tc/3379:
[ 582.641049] #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff910354ce>] rtnetlink_rcv_msg+0x92e/0x1400
[ 582.650958] #1: (&(&tn->idrinfo->lock)->rlock){+.-.+.}, at: [<ffffffff9110a5e0>] tcf_idr_create+0x2f0/0x8e0
[ 582.662217] Preemption disabled at:
[ 582.662222] [<ffffffff9110a5e0>] tcf_idr_create+0x2f0/0x8e0
[ 582.672592] CPU: 9 PID: 3379 Comm: tc Tainted: G W 4.13.0-rc7-debug-00648-g43503a79b9f0 #287
[ 582.683432] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 11/08/2016
[ 582.691937] Call Trace:
...
[ 582.713332] ? tcf_idr_create+0x2f0/0x8e0
[ 582.717925] ___might_sleep+0x40f/0x660
[ 582.722336] ? finish_task_switch+0xb90/0xb90
[ 582.727315] ? mark_held_locks+0xdd/0x190
[ 582.731908] __might_sleep+0xba/0x240
[ 582.736125] ? radix_tree_node_alloc.constprop.6+0x4a/0x450
[ 582.742460] kmem_cache_alloc+0x286/0x540
[ 582.747055] radix_tree_node_alloc.constprop.6+0x4a/0x450
[ 582.753209] idr_get_free_cmn+0x627/0xf80
...
[ 582.815525] idr_alloc_cmn+0x1a8/0x270
[ 582.819821] ? __raw_spin_lock_init+0x21/0x120
[ 582.824914] ? idr_replace+0x20/0x20
[ 582.829013] ? do_raw_spin_lock+0x1f0/0x1f0
[ 582.833804] tcf_idr_create+0x31b/0x8e0
...
Fixes: 65a206c01e8e ("net/sched: Change act_api and act_xxx modules to use IDR")
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
---
net/sched/act_api.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index 0eb545bcb247..a48e4b45722d 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -298,7 +298,7 @@ int tcf_idr_create(struct tc_action_net *tn, u32 index, struct nlattr *est,
if (!index) {
spin_lock_bh(&idrinfo->lock);
err = idr_alloc_ext(idr, NULL, &idr_index, 1, 0,
- GFP_KERNEL);
+ GFP_ATOMIC);
spin_unlock_bh(&idrinfo->lock);
if (err) {
err3:
@@ -309,7 +309,7 @@ int tcf_idr_create(struct tc_action_net *tn, u32 index, struct nlattr *est,
} else {
spin_lock_bh(&idrinfo->lock);
err = idr_alloc_ext(idr, NULL, NULL, index, index + 1,
- GFP_KERNEL);
+ GFP_ATOMIC);
spin_unlock_bh(&idrinfo->lock);
if (err)
goto err3;
--
2.14.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox