* Re: [PATCH] of_mdio: use of_property_read_u32_array()
From: David Miller @ 2017-08-07 21:07 UTC (permalink / raw)
To: sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8
Cc: andrew-g2DYL2Zd6BY, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170804214354.351406407-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
From: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Date: Sat, 05 Aug 2017 00:43:43 +0300
> The "fixed-link" prop support predated of_property_read_u32_array(), so
> basically had to open-code it. Using the modern API saves 24 bytes of the
> object code (ARM gcc 4.8.5); the only behavior change would be that the
> prop length check is now less strict (however the strict pre-check done
> in of_phy_is_fixed_link() is left intact anyway)...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Applied to net-next.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] wan: dscc4: add checks for dma mapping errors
From: David Miller @ 2017-08-07 21:06 UTC (permalink / raw)
To: khoroshilov; +Cc: romieu, netdev, linux-kernel, ldv-project
In-Reply-To: <1501878204-24270-1-git-send-email-khoroshilov@ispras.ru>
From: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date: Fri, 4 Aug 2017 23:23:24 +0300
> The driver does not check if mapping dma memory succeed.
> The patch adds the checks and failure handling.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
This is a great example of why it can be irritating to see these
mechanical "bug fixes" for drivers very few people use and actually
test, which introduces new bugs.
> @@ -522,19 +522,27 @@ static inline int try_get_rx_skb(struct dscc4_dev_priv *dpriv,
> struct RxFD *rx_fd = dpriv->rx_fd + dirty;
> const int len = RX_MAX(HDLC_MAX_MRU);
> struct sk_buff *skb;
> - int ret = 0;
> + dma_addr_t addr;
>
> skb = dev_alloc_skb(len);
> dpriv->rx_skbuff[dirty] = skb;
skb recorded here.
> +err_free_skb:
> + dev_kfree_skb_any(skb);
Yet freed here in the error path.
dpriv->rx_skbuff[dirty] should not be set to 'skb' until all possibile
failure tests have passed.
^ permalink raw reply
* unregister_netdevice: waiting for eth0 to become free. Usage count = 1
From: John Stultz @ 2017-08-07 21:05 UTC (permalink / raw)
To: lkml, Network Development, Linux USB List, David S. Miller,
Felipe Balbi
So, with recent testing with my HiKey board, I've been noticing some
quirky behavior with my USB eth adapter.
Basically, pluging the usb eth adapter in and then removing it, when
plugging it back in I often find that its not detected, and the system
slowly spits out the following message over and over:
unregister_netdevice: waiting for eth0 to become free. Usage count = 1
I've tried to go through and bisect it, but apparently the issue isn't
always reproducible, as I'm apparently getting lots of false negatives
(where I can't always reproduce boot to boot the issue on the same
kernel).
I've done three bisection passes (always restarting with the "first
bad commit" from the previous bisection as the initial bad commit for
the following pass), and it does seem to keep moving back. But it
seems much easier to trigger with newer kernels then older (and so far
I've not seen it with 4.12).
Wanted to see if anyone had any ideas what might be going wrong, and
how I should further debug this.
The last bisect log I generated was:
# good: [6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c] Linux 4.12
git bisect good 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c
# bad: [98fdd857a3bd6a3bf0003d3f68f07c25c85dcde3] net: ethernet: ti:
cpsw: move skb timestamp to packet_submit
git bisect bad 98fdd857a3bd6a3bf0003d3f68f07c25c85dcde3
# good: [48b6bbef9a1789f0365c1a385879a1fea4460016] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
git bisect good 48b6bbef9a1789f0365c1a385879a1fea4460016
# good: [a2e8bbd2ef5457485f00b6b947bbbfa2778e5b1e] bpf: Fix
test_obj_id.c for llvm 5.0
git bisect good a2e8bbd2ef5457485f00b6b947bbbfa2778e5b1e
# good: [273889e306256e95ea55d5ebaef99310cf589def] Merge tag
'mlx5-updates-2017-06-16' of
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
git bisect good 273889e306256e95ea55d5ebaef99310cf589def
# bad: [8f46d46715a12f509e13200033a1ed4d6cf335ff] cxgb4: Use Firmware
params to get buffer-group map
git bisect bad 8f46d46715a12f509e13200033a1ed4d6cf335ff
# bad: [f5c306470ed0a8f03ba7017f397da2555b5800d4] Merge tag
'mlx5-updates-2017-06-20' of
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
git bisect bad f5c306470ed0a8f03ba7017f397da2555b5800d4
# bad: [e289ef0ded13021db292be9aef134451546e7c60] net: dsa: mv88e6xxx:
clarify SMI PHY functions
git bisect bad e289ef0ded13021db292be9aef134451546e7c60
# bad: [836d57e5c08e13bb206dcd559d96ee9355e8316e] liquidio: implement
vlan filter enable and disable
git bisect bad 836d57e5c08e13bb206dcd559d96ee9355e8316e
# bad: [ad65a2f05695aced349e308193c6e2a6b1d87112] ipv6: call
dst_hold_safe() properly
git bisect bad ad65a2f05695aced349e308193c6e2a6b1d87112
# good: [0830106c53900181d336350581119af09e123bf3] ipv4: take
dst->__refcnt when caching dst in fib
git bisect good 0830106c53900181d336350581119af09e123bf3
# good: [b838d5e1c5b6e57b10ec8af2268824041e3ea911] ipv4: mark DST_NOGC
and remove the operation of dst_free()
git bisect good b838d5e1c5b6e57b10ec8af2268824041e3ea911
# bad: [9514528d92d4cbe086499322370155ed69f5d06c] ipv6: call
dst_dev_put() properly
git bisect bad 9514528d92d4cbe086499322370155ed69f5d06c
# good: [1cfb71eeb12047bcdbd3e6730ffed66e810a0855] ipv6: take
dst->__refcnt for insertion into fib6 tree
git bisect good 1cfb71eeb12047bcdbd3e6730ffed66e810a0855
# first bad commit: [9514528d92d4cbe086499322370155ed69f5d06c] ipv6:
call dst_dev_put() properly
But again, reverting the "ipv6: call dst_dev_put() properly" commit
doesn't seem to completely resolve the issue on newer kernels (though
it may make it harder to trigger), and I suspect with further
bisection passes I might move further back.
Ideas? I don't seem to have similar issues with USB mass storage
devices, so it seems to be networking specific.
thanks
-john
^ permalink raw reply
* Re: [PATCH net] net: sched: set xt_tgchk_param par.nft_compat with false in ipt_init_target
From: Cong Wang @ 2017-08-07 21:03 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, David Miller, Pablo Neira Ayuso
In-Reply-To: <985e6cb7c94f0014096ebca47e1efd74e022dc8d.1501932779.git.lucien.xin@gmail.com>
On Sat, Aug 5, 2017 at 4:32 AM, Xin Long <lucien.xin@gmail.com> wrote:
> Commit 55917a21d0cc ("netfilter: x_tables: add context to know if
> extension runs from nft_compat") introduced a member nft_compat to
> xt_tgchk_param structure.
>
> But it didn't set it's value for ipt_init_target. With unexpected
> value in par.nft_compat, it may return unexpected result in some
> target's checkentry.
>
> This patch is to set par.nft_compat with false in ipt_init_target.
It's time to set all these fields to 0 and only initialize those non-zero
fields, in case we will add more fields in the future.
^ permalink raw reply
* Re: [PATCH net v2] net/mlx4_en: don't set CHECKSUM_COMPLETE on SCTP packets
From: David Miller @ 2017-08-07 21:03 UTC (permalink / raw)
To: dcaratti; +Cc: tariqt, netdev
In-Reply-To: <23ac3e005a8dc1a373971f1166fe6ba72d8abe4b.1501793448.git.dcaratti@redhat.com>
From: Davide Caratti <dcaratti@redhat.com>
Date: Thu, 3 Aug 2017 22:54:48 +0200
> if the NIC fails to validate the checksum on TCP/UDP, and validation of IP
> checksum is successful, the driver subtracts the pseudo-header checksum
> from the value obtained by the hardware and sets CHECKSUM_COMPLETE. Don't
> do that if protocol is IPPROTO_SCTP, otherwise CRC32c validation fails.
>
> V2: don't test MLX4_CQE_STATUS_IPV6 if MLX4_CQE_STATUS_IPV4 is set
>
> Reported-by: Shuang Li <shuali@redhat.com>
> Fixes: f8c6455bb04b ("net/mlx4_en: Extend checksum offloading by CHECKSUM COMPLETE")
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Can I get reviews from some Mellanox folks please?
^ permalink raw reply
* Re: [PATCH net-next] ibmvnic: Report rx buffer return codes as netdev_dbg
From: David Miller @ 2017-08-07 21:01 UTC (permalink / raw)
To: jallen; +Cc: netdev, nfont, tlfalcon
In-Reply-To: <21089a62-0b49-ef34-6eb0-33510a5638c0@linux.vnet.ibm.com>
From: John Allen <jallen@linux.vnet.ibm.com>
Date: Mon, 7 Aug 2017 15:42:30 -0500
> Reporting any return code for a receive buffer as an "rx error" only
> produces alarming noise and the only values that have been observed to be
> used in this field are not error conditions. Change this to a netdev_dbg
> with a more descriptive message.
>
> Signed-off-by: John Allen <jallen@linux.vnet.ibm.com>
Applied, thanks John.
^ permalink raw reply
* Re: [PATCH net] net: sched: set xt_tgchk_param par.net properly in ipt_init_target
From: Cong Wang @ 2017-08-07 21:00 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, David Miller
In-Reply-To: <6252aa0d498204ec3431e9a906178fb6b1c97f00.1501922918.git.lucien.xin@gmail.com>
On Sat, Aug 5, 2017 at 1:48 AM, Xin Long <lucien.xin@gmail.com> wrote:
> -static int __tcf_ipt_init(struct tc_action_net *tn, struct nlattr *nla,
> +static int __tcf_ipt_init(struct net *net, struct nlattr *nla,
> struct nlattr *est, struct tc_action **a,
> const struct tc_action_ops *ops, int ovr, int bind)
> {
> + struct tc_action_net *tn = net_generic(net, xt_net_id);
...
> @@ -193,18 +195,14 @@ static int tcf_ipt_init(struct net *net, struct nlattr *nla,
> struct nlattr *est, struct tc_action **a, int ovr,
> int bind)
> {
> - struct tc_action_net *tn = net_generic(net, ipt_net_id);
> -
> - return __tcf_ipt_init(tn, nla, est, a, &act_ipt_ops, ovr, bind);
> + return __tcf_ipt_init(net, nla, est, a, &act_ipt_ops, ovr, bind);
> }
>
> static int tcf_xt_init(struct net *net, struct nlattr *nla,
> struct nlattr *est, struct tc_action **a, int ovr,
> int bind)
> {
> - struct tc_action_net *tn = net_generic(net, xt_net_id);
> -
> - return __tcf_ipt_init(tn, nla, est, a, &act_xt_ops, ovr, bind);
> + return __tcf_ipt_init(net, nla, est, a, &act_xt_ops, ovr, bind);
This is not correct.
You miss ipt_net_id != xt_net_id.
^ permalink raw reply
* [PATCH net-next] ibmvnic: Report rx buffer return codes as netdev_dbg
From: John Allen @ 2017-08-07 20:42 UTC (permalink / raw)
To: netdev; +Cc: Nathan Fontenot, Thomas Falcon
Reporting any return code for a receive buffer as an "rx error" only
produces alarming noise and the only values that have been observed to be
used in this field are not error conditions. Change this to a netdev_dbg
with a more descriptive message.
Signed-off-by: John Allen <jallen@linux.vnet.ibm.com>
---
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 5932160..99576ba 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1579,7 +1579,8 @@ static int ibmvnic_poll(struct napi_struct *napi, int budget)
rx_comp.correlator);
/* do error checking */
if (next->rx_comp.rc) {
- netdev_err(netdev, "rx error %x\n", next->rx_comp.rc);
+ netdev_dbg(netdev, "rx buffer returned with rc %x\n",
+ be16_to_cpu(next->rx_comp.rc));
/* free the entry */
next->rx_comp.first = 0;
remove_buff_from_pool(adapter, rx_buff);
^ permalink raw reply related
* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
From: David Miller @ 2017-08-07 20:26 UTC (permalink / raw)
To: stephen; +Cc: dsahern, simon.horman, daniel, phil, netdev
In-Reply-To: <20170807121235.4a8b5020@xeon-e3>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Mon, 7 Aug 2017 12:12:35 -0700
> Dave, I asked for test cases, and received none.
You don't need a test case to type make and make sure the build succeeds.
^ permalink raw reply
* [PATCH net-next] selftests: bpf: add a test for XDP redirect
From: William Tu @ 2017-08-07 20:14 UTC (permalink / raw)
To: netdev; +Cc: Daniel Borkmann, John Fastabend
Add test for xdp_redirect by creating two namespaces with two
veth peers, then forward packets in-between.
Signed-off-by: William Tu <u9012063@gmail.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: John Fastabend <john.fastabend@gmail.com>
---
tools/include/uapi/linux/bpf.h | 3 +-
tools/testing/selftests/bpf/Makefile | 4 +-
tools/testing/selftests/bpf/test_xdp_redirect.c | 28 ++++++++++++
tools/testing/selftests/bpf/test_xdp_redirect.sh | 54 ++++++++++++++++++++++++
4 files changed, 86 insertions(+), 3 deletions(-)
create mode 100644 tools/testing/selftests/bpf/test_xdp_redirect.c
create mode 100755 tools/testing/selftests/bpf/test_xdp_redirect.sh
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 1579cab49717..8d9bfcca3fe4 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -592,7 +592,8 @@ union bpf_attr {
FN(get_socket_uid), \
FN(set_hash), \
FN(setsockopt), \
- FN(skb_adjust_room),
+ FN(skb_adjust_room), \
+ FN(redirect_map),
/* integer value in 'imm' field of BPF_CALL instruction selects which helper
* function eBPF program intends to call
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index 153c3a181a4c..3c2e67da4b41 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -15,9 +15,9 @@ TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map test
test_align
TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o test_tcp_estats.o test_obj_id.o \
- test_pkt_md_access.o
+ test_pkt_md_access.o test_xdp_redirect.o
-TEST_PROGS := test_kmod.sh
+TEST_PROGS := test_kmod.sh test_xdp_redirect.sh
include ../lib.mk
diff --git a/tools/testing/selftests/bpf/test_xdp_redirect.c b/tools/testing/selftests/bpf/test_xdp_redirect.c
new file mode 100644
index 000000000000..ef9e704be140
--- /dev/null
+++ b/tools/testing/selftests/bpf/test_xdp_redirect.c
@@ -0,0 +1,28 @@
+/* Copyright (c) 2017 VMware
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of version 2 of the GNU General Public
+ * License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+#include <linux/bpf.h>
+#include "bpf_helpers.h"
+
+int _version SEC("version") = 1;
+
+SEC("redirect_to_111")
+int xdp_redirect_to_111(struct xdp_md *xdp)
+{
+ return bpf_redirect(111, 0);
+}
+SEC("redirect_to_222")
+int xdp_redirect_to_222(struct xdp_md *xdp)
+{
+ return bpf_redirect(222, 0);
+}
+
+char _license[] SEC("license") = "GPL";
diff --git a/tools/testing/selftests/bpf/test_xdp_redirect.sh b/tools/testing/selftests/bpf/test_xdp_redirect.sh
new file mode 100755
index 000000000000..d8c73ed6e040
--- /dev/null
+++ b/tools/testing/selftests/bpf/test_xdp_redirect.sh
@@ -0,0 +1,54 @@
+#!/bin/sh
+# Create 2 namespaces with two veth peers, and
+# forward packets in-between using generic XDP
+#
+# NS1(veth11) NS2(veth22)
+# | |
+# | |
+# (veth1, ------ (veth2,
+# id:111) id:222)
+# | xdp forwarding |
+# ------------------
+
+cleanup()
+{
+ if [ "$?" = "0" ]; then
+ echo "selftests: test_xdp_redirect [PASS]";
+ else
+ echo "selftests: test_xdp_redirect [FAILED]";
+ fi
+
+ set +e
+ ip netns del ns1 2> /dev/null
+ ip netns del ns2 2> /dev/null
+}
+
+set -e
+
+ip netns add ns1
+ip netns add ns2
+
+trap cleanup 0 2 3 6 9
+
+ip link add veth1 index 111 type veth peer name veth11
+ip link add veth2 index 222 type veth peer name veth22
+
+ip link set veth11 netns ns1
+ip link set veth22 netns ns2
+
+ip link set veth1 up
+ip link set veth2 up
+
+ip netns exec ns1 ip addr add 10.1.1.11/24 dev veth11
+ip netns exec ns2 ip addr add 10.1.1.22/24 dev veth22
+
+ip netns exec ns1 ip link set dev veth11 up
+ip netns exec ns2 ip link set dev veth22 up
+
+ip link set dev veth1 xdpgeneric obj test_xdp_redirect.o sec redirect_to_222
+ip link set dev veth2 xdpgeneric obj test_xdp_redirect.o sec redirect_to_111
+
+ip netns exec ns1 ping -c 1 10.1.1.22
+ip netns exec ns2 ping -c 1 10.1.1.11
+
+exit 0
--
2.7.4
^ permalink raw reply related
* Re: Qdisc->u32_node - licence to kill
From: John Fastabend @ 2017-08-07 19:54 UTC (permalink / raw)
To: Jiri Pirko; +Cc: jhs, xiyou.wangcong, davem, netdev, mlxsw
In-Reply-To: <20170807190624.GL2085@nanopsycho.orion>
On 08/07/2017 12:06 PM, Jiri Pirko wrote:
> Mon, Aug 07, 2017 at 07:47:14PM CEST, john.fastabend@gmail.com wrote:
>> On 08/07/2017 09:41 AM, Jiri Pirko wrote:
>>> Hi Jamal/Cong/David/all.
>>>
>>> Digging in the u32 code deeper now. I need to get rid of tp->q for shared
>>> blocks, but I found out about this:
>>>
>>> struct Qdisc {
>>> ......
>>> void *u32_node;
>>> ......
>>> };
>>>
>>> Yeah, ugly. u32 uses it to store some shared data, tp_c. It actually
>>> stores a linked list of all hashtables added to one qdiscs.
>>>
>>> So basically what you have is, you have 1 root ht per prio/pref. Then
>>> you can have multiple hts, linked from any other ht, does not matter in
>>> which prio/pref they are.
>>>
>>
>> We can create arbitrary hash tables here independent of prio/pref via
>> TCA_U32_DIVISOR. Then these can be linked to other hash tables via
>> TCA_U32_LINK commands.
>
> Yeah, that's what I thought.
>
>
>>
>> prio/pref does not really play any part here from my reading, except as
>> a further specifier in the walk callbacks. Making it a useful filter on
>> dump operations.
>
> Not correct. prio/pref is one level up priority, independent on specific
> cls implementation. You can have cls_u32 instance on prio 10 and
> cls_flower instance on prio 20. Both work.
ah right, lets make sure I got this right then (its been awhile since I've
read this code). So the tcf_ctl_tfilter hook walks classifiers, inserting the
classifier by prio. Then tcf_classify walks the list of classifiers looking
for any matches, specifically any return codes it recognizes or a return code
greater than zero. u32 though has this link notion that allows users to jump
to other u32 classifiers that are in this list, because it has a global hash
table list. So the per prio classifier isolation is not true in u32 case.
>
> In fact, the current u32 "linking" ignores the upper level
> prio/pref and breakes user assumptions when he inserts rules with
> specific prio.
>
>
hmm yep, I guess users of u32 have a "different" set of assumptions when
working with u32 hash tables than the rest of the classifiers.
>>
>>> Do I understand that correctly that prio/pref only has meaning if
>>> linking does not take place, because if there is linking, the prio/pref
>>> of inserted rule is simply ignored?
>>
>> I think even then the prio/pref meaning is dubious, from u32_change,
>
> Please see tc_ctl_tfilter. That is where prio/pref is processed. What
> you describe is one level down.
>
got it.
>
>>
>> for (pins = rtnl_dereference(*ins); pins;
>> ins = &pins->next, pins = rtnl_dereference(*ins))
>> if (TC_U32_NODE(handle) < TC_U32_NODE(pins->handle))
>> break;
>>
>> I think the list insert is done via handle not via prio/pref.
>>
>>>
>>> That is the most confusing thing I saw in net/sched/ so far.
>>> Is this a bug? Sounds like one.
>>>
>>
>> I don't think this is a bug at very least I don't see how we can
>> change it without breaking users. I know people depend on the hash map
>> capabilities and linking logic.
>
> Do they insert rules into multiple hashtables with different prio? Why?
> What is the usecase?
>
Single u32 classifier with multiple hash tables linked together I would
think is the normal way. I guess because the API never disallowed it
and the user api is a bit tricky its possible users may use multiple prios,
but probably it is not needed.
Maybe Jamal has some use case where this is required?
>
>>
>>> Did someone introduce *u32_node (formerly static struct tc_u_common
>>> *u32_list;) just to allow this weirdness?
>>>
>>> Can I just remove this shared tp_c and make the linking to other
>>> hashtables only possible within the same prio/pref? That would make
>>> sense to me.
>>>
>>
>> The idea to make linking hash tables only possible within the same
>> prio/pref will break existing programs. We can't do this its part of
>> UAPI now and people depend on it.
>
> That's why I asked if that is a bug. I still feel it is. But I
> definitelly understand your concern. I'm just trying to figure out how
> to resolve this misdesign :(
>
I don't have a good argument for the current design, but just want to be
sure we don't break existing users.
.John
^ permalink raw reply
* Re: [PATCH iproute2] lib: Dump ext-ack string by default
From: David Ahern @ 2017-08-07 19:36 UTC (permalink / raw)
To: netdev, stephen
In-Reply-To: <1502134082-4602-1-git-send-email-dsahern@gmail.com>
On 8/7/17 1:28 PM, David Ahern wrote:
> @@ -99,7 +95,12 @@ 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);
> +
> + fprintf(stderr, "Error: %s\n", errmsg);
> +
> + return 1;
Dang it, missing an 'if (errmsg)' since it does not have to exist. Will
send a v2
^ permalink raw reply
* Re: [pull request][for-next 0/8] Mellanox, mlx5 shared 2017-08-07
From: Saeed Mahameed @ 2017-08-07 19:31 UTC (permalink / raw)
To: David Miller
Cc: Saeed Mahameed, Doug Ledford, Linux Netdev List,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky
In-Reply-To: <20170807.112052.332868856082904160.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Mon, Aug 7, 2017 at 9:20 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> From: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Date: Mon, 7 Aug 2017 13:18:00 +0300
>
>> Hi Dave & Doug,
>>
>> This series contains some low level updates for mlx5 core driver,
>> to be shared as base code for net-next and rdma for-next mlx5
>> 4.14 submissions.
>>
>> Please find more information in the tag message below.
>>
>> Please pull and let me know if there's any porblem.
>>
>> Side note:
>> This series merges cleanly with current net-next, but it will conflict with Jiri's patch
>> "mlx5e: push cls_flower and mqprio setup_tc processing into separate functions"
>> Which is under review.
>> since this is shared code and must go to both rdma and net-next it has to be
>> based on 4.13-rc4, so there is not much I can do about this.
>
> I resolved the merge conflict as best as I could, please take a look.
>
Thanks Dave!
looks good, I will do some compilation testing later and if i find
anything i will post a patch.
Thanks a lot,
-Saeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH iproute2] lib: Dump ext-ack string by default
From: David Ahern @ 2017-08-07 19:28 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>
---
lib/libnetlink.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 145de2cb0ccf..ee78f768a8bd 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,12 @@ 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);
+
+ fprintf(stderr, "Error: %s\n", errmsg);
+
+ return 1;
}
#else
#warning "libmnl required for error support"
--
2.1.4
^ permalink raw reply related
* [PATCH net-next] liquidio: fix misspelled firmware image filenames
From: Felix Manlunas @ 2017-08-07 19:22 UTC (permalink / raw)
To: davem; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
From: Derek Chickles <derek.chickles@cavium.com>
Fix misspelled firmware image filenames advertised via MODULE_FIRMWARE().
Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
---
drivers/net/ethernet/cavium/liquidio/lio_main.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 8c2cd80..3ec0dd9 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -39,10 +39,14 @@ MODULE_AUTHOR("Cavium Networks, <support@cavium.com>");
MODULE_DESCRIPTION("Cavium LiquidIO Intelligent Server Adapter Driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(LIQUIDIO_VERSION);
-MODULE_FIRMWARE(LIO_FW_DIR LIO_FW_BASE_NAME LIO_210SV_NAME LIO_FW_NAME_SUFFIX);
-MODULE_FIRMWARE(LIO_FW_DIR LIO_FW_BASE_NAME LIO_210NV_NAME LIO_FW_NAME_SUFFIX);
-MODULE_FIRMWARE(LIO_FW_DIR LIO_FW_BASE_NAME LIO_410NV_NAME LIO_FW_NAME_SUFFIX);
-MODULE_FIRMWARE(LIO_FW_DIR LIO_FW_BASE_NAME LIO_23XX_NAME LIO_FW_NAME_SUFFIX);
+MODULE_FIRMWARE(LIO_FW_DIR LIO_FW_BASE_NAME LIO_210SV_NAME
+ "_" LIO_FW_NAME_TYPE_NIC LIO_FW_NAME_SUFFIX);
+MODULE_FIRMWARE(LIO_FW_DIR LIO_FW_BASE_NAME LIO_210NV_NAME
+ "_" LIO_FW_NAME_TYPE_NIC LIO_FW_NAME_SUFFIX);
+MODULE_FIRMWARE(LIO_FW_DIR LIO_FW_BASE_NAME LIO_410NV_NAME
+ "_" LIO_FW_NAME_TYPE_NIC LIO_FW_NAME_SUFFIX);
+MODULE_FIRMWARE(LIO_FW_DIR LIO_FW_BASE_NAME LIO_23XX_NAME
+ "_" LIO_FW_NAME_TYPE_NIC LIO_FW_NAME_SUFFIX);
static int ddr_timeout = 10000;
module_param(ddr_timeout, int, 0644);
^ permalink raw reply related
* Re: [PATCH 0/6] In-kernel QMI handling
From: Marcel Holtmann @ 2017-08-07 19:19 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Dan Williams, David S. Miller, Andy Gross, David Brown,
linux-arm-msm, linux-soc, Netdev list, linux-kernel
In-Reply-To: <20170807173842.GI29306@minitux>
Hi Bjorn,
>>> This series starts by moving the common definitions of the QMUX
>>> protocol to the
>>> uapi header, as they are shared with clients - both in kernel and
>>> userspace.
>>>
>>> This series then introduces in-kernel helper functions for aiding the
>>> handling
>>> of QMI encoded messages in the kernel. QMI encoding is a wire-format
>>> used in
>>> exchanging messages between the majority of QRTR clients and
>>> services.
>>
>> This raises a few red-flags for me.
>
> I'm glad it does. In discussions with the responsible team within
> Qualcomm I've highlighted a number of concerns about enabling this
> support in the kernel. Together we're continuously looking into what
> should be pushed out to user space, and trying to not introduce
> unnecessary new users.
>
>> So far, we've kept almost everything QMI related in userspace and
>> handled all QMI control-channel messages from libraries like libqmi or
>> uqmi via the cdc-wdm driver and the "rmnet" interface via the qmi_wwan
>> driver. The kernel drivers just serve as the transport.
>>
>
> The path that was taken to support the MSM-style devices was to
> implement net/qrtr, which exposes a socket interface to abstract the
> physical transports (QMUX or IPCROUTER in Qualcomm terminology).
>
> As I share you view on letting the kernel handle the transportation only
> the task of keeping track of registered services (service id -> node and
> port mapping) was done in a user space process and so far we've only
> ever have to deal with QMI encoded messages in various user space tools.
I think that the transport and multiplexing can be in the kernel as long as it is done as proper subsystem. Similar to Phonet or CAIF. Meaning it should have a well defined socket interface that can be easily used from userspace, but also a clean in-kernel interface handling.
If Qualcomm is supportive of this effort and is willing to actually assist and/or open some of the specs or interface descriptions, then this is a good thing. Service registration and cleanup is really done best in the kernel. Same applies to multiplexing. Trying to do multiplexing in userspace is always cumbersome and leads to overhead that is of no gain. For example within oFono, we had to force everything to go via oFono since it was the only sane way of handling it. Other approaches were error prone and full of race conditions. You need a central entity that can clean up.
For the definition of an UAPI to share some code, I am actually not sure that is such a good idea. For example the QMI code in oFono follows a way simpler approach. And I am not convinced that all the macros are actually beneficial. For example, the whole netlink macros are pretty cumbersome. Adding some Documentation/qmi.txt on how the wire format looks like and what is expected seems to be a way better approach.
Regards
Marcel
^ permalink raw reply
* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
From: Stephen Hemminger @ 2017-08-07 19:12 UTC (permalink / raw)
To: David Miller; +Cc: dsahern, simon.horman, daniel, phil, netdev
In-Reply-To: <20170807.114517.1570408214504753399.davem@davemloft.net>
On Mon, 07 Aug 2017 11:45:17 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: David Ahern <dsahern@gmail.com>
> Date: Mon, 7 Aug 2017 12:09:31 -0600
>
> > On 8/7/17 12:06 PM, Stephen Hemminger wrote:
> >>> Does not work. Seems like you pushed the RFC commit which was known to
> >>> be incomplete.
> >>
> >> Patches welcome.
> >
> > What exists does not even compile. Patches will be sent once you fix that.
>
> Yeah seriously Stephen, you created this huge mess so the onus is really
> on you to fix it up.
It is fixed now.
Dave, I asked for test cases, and received none.
^ permalink raw reply
* Re: Qdisc->u32_node - licence to kill
From: Jiri Pirko @ 2017-08-07 19:06 UTC (permalink / raw)
To: John Fastabend; +Cc: jhs, xiyou.wangcong, davem, netdev, mlxsw
In-Reply-To: <5988A7A2.3090200@gmail.com>
Mon, Aug 07, 2017 at 07:47:14PM CEST, john.fastabend@gmail.com wrote:
>On 08/07/2017 09:41 AM, Jiri Pirko wrote:
>> Hi Jamal/Cong/David/all.
>>
>> Digging in the u32 code deeper now. I need to get rid of tp->q for shared
>> blocks, but I found out about this:
>>
>> struct Qdisc {
>> ......
>> void *u32_node;
>> ......
>> };
>>
>> Yeah, ugly. u32 uses it to store some shared data, tp_c. It actually
>> stores a linked list of all hashtables added to one qdiscs.
>>
>> So basically what you have is, you have 1 root ht per prio/pref. Then
>> you can have multiple hts, linked from any other ht, does not matter in
>> which prio/pref they are.
>>
>
>We can create arbitrary hash tables here independent of prio/pref via
>TCA_U32_DIVISOR. Then these can be linked to other hash tables via
>TCA_U32_LINK commands.
Yeah, that's what I thought.
>
>prio/pref does not really play any part here from my reading, except as
>a further specifier in the walk callbacks. Making it a useful filter on
>dump operations.
Not correct. prio/pref is one level up priority, independent on specific
cls implementation. You can have cls_u32 instance on prio 10 and
cls_flower instance on prio 20. Both work.
In fact, the current u32 "linking" ignores the upper level
prio/pref and breakes user assumptions when he inserts rules with
specific prio.
>
>> Do I understand that correctly that prio/pref only has meaning if
>> linking does not take place, because if there is linking, the prio/pref
>> of inserted rule is simply ignored?
>
>I think even then the prio/pref meaning is dubious, from u32_change,
Please see tc_ctl_tfilter. That is where prio/pref is processed. What
you describe is one level down.
>
> for (pins = rtnl_dereference(*ins); pins;
> ins = &pins->next, pins = rtnl_dereference(*ins))
> if (TC_U32_NODE(handle) < TC_U32_NODE(pins->handle))
> break;
>
>I think the list insert is done via handle not via prio/pref.
>
>>
>> That is the most confusing thing I saw in net/sched/ so far.
>> Is this a bug? Sounds like one.
>>
>
>I don't think this is a bug at very least I don't see how we can
>change it without breaking users. I know people depend on the hash map
>capabilities and linking logic.
Do they insert rules into multiple hashtables with different prio? Why?
What is the usecase?
>
>> Did someone introduce *u32_node (formerly static struct tc_u_common
>> *u32_list;) just to allow this weirdness?
>>
>> Can I just remove this shared tp_c and make the linking to other
>> hashtables only possible within the same prio/pref? That would make
>> sense to me.
>>
>
>The idea to make linking hash tables only possible within the same
>prio/pref will break existing programs. We can't do this its part of
>UAPI now and people depend on it.
That's why I asked if that is a bug. I still feel it is. But I
definitelly understand your concern. I'm just trying to figure out how
to resolve this misdesign :(
^ permalink raw reply
* Re: [PATCH net-next v4 1/2] bpf: add support for sys_enter_* and sys_exit_* tracepoints
From: Alexei Starovoitov @ 2017-08-07 18:51 UTC (permalink / raw)
To: Yonghong Song, peterz, rostedt, daniel, netdev; +Cc: kernel-team
In-Reply-To: <20170804230010.2792119-2-yhs@fb.com>
On 8/4/17 1:00 PM, Yonghong Song wrote:
> Currently, bpf programs cannot be attached to sys_enter_* and sys_exit_*
> style tracepoints. The iovisor/bcc issue #748
> (https://github.com/iovisor/bcc/issues/748) documents this issue.
> For example, if you try to attach a bpf program to tracepoints
> syscalls/sys_enter_newfstat, you will get the following error:
> # ./tools/trace.py t:syscalls:sys_enter_newfstat
> Ioctl(PERF_EVENT_IOC_SET_BPF): Invalid argument
> Failed to attach BPF to tracepoint
>
> The main reason is that syscalls/sys_enter_* and syscalls/sys_exit_*
> tracepoints are treated differently from other tracepoints and there
> is no bpf hook to it.
>
> This patch adds bpf support for these syscalls tracepoints by
> . permitting bpf attachment in ioctl PERF_EVENT_IOC_SET_BPF
> . calling bpf programs in perf_syscall_enter and perf_syscall_exit
>
> The legality of bpf program ctx access is also checked.
> Function trace_event_get_offsets returns correct max offset for each
> specific syscall tracepoint, which is compared against the maximum offset
> access in bpf program.
>
> Signed-off-by: Yonghong Song <yhs@fb.com>
lgtm
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next v3 00/13] Update DSA's FDB API and perform switchdev cleanup
From: Florian Fainelli @ 2017-08-07 18:48 UTC (permalink / raw)
To: Vivien Didelot, Arkadi Sharshevsky, netdev
Cc: davem, jiri, ivecera, andrew, Woojung.Huh, mlxsw
In-Reply-To: <87bmnrifte.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
On 08/07/2017 07:59 AM, Vivien Didelot wrote:
> Hi Arkadi,
>
> Arkadi Sharshevsky <arkadis@mellanox.com> writes:
>
>> The patchset adds support for configuring static FDB entries via the
>> switchdev notification chain. The current method for FDB configuration
>> uses the switchdev's bridge bypass implementation. In order to support
>> this legacy way and to perform the switchdev cleanup, the implementation
>> is moved inside DSA.
>>
>> The DSA drivers cannot sync the software bridge with hardware learned
>> entries and use the switchdev's implementation of bypass FDB dumping.
>> Because they are the only ones using this functionality, the fdb_dump
>> implementation is moved from switchdev code into DSA.
>>
>> Finally after this changes a major cleanup in switchdev can be done.
>> ---
>> Please see individual patches for patch specific change logs.
>> v1->v2
>> - Split MDB/vlan dump removal into core/driver removal.
>>
>> v2->v3
>> - The self implementation for FDB add/del is moved inside DSA.
>
> v3 behaves correctly:
>
> # bridge fdb add e4:1d:2d:a5:f0:2a dev lan3
> # bridge fdb add e4:1d:2d:a5:f0:4a dev lan4 master
> # bridge fdb show
> 01:00:5e:00:00:01 dev eth0 self permanent
> 01:00:5e:00:00:01 dev eth1 self permanent
> b6:f2:c8:3a:1c:71 dev lan0 master br0 permanent
> e4:1d:2d:a5:f0:2a dev lan3 self static
> e4:1d:2d:a5:f0:4a dev lan4 offload master br0 permanent
> e4:1d:2d:a5:f0:4a dev lan4 self static
> 01:00:5e:00:00:01 dev br0 self permanent
> # bridge fdb del e4:1d:2d:a5:f0:2a dev lan3
> # bridge fdb del e4:1d:2d:a5:f0:4a dev lan4 master
> # bridge fdb show
> 01:00:5e:00:00:01 dev eth0 self permanent
> 01:00:5e:00:00:01 dev eth1 self permanent
> b6:f2:c8:3a:1c:71 dev lan0 master br0 permanent
> 01:00:5e:00:00:01 dev br0 self permanent
>
> Tested-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Same here:
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH] of_mdio: use of_property_read_u32_array()
From: Rob Herring @ 2017-08-07 18:44 UTC (permalink / raw)
To: Florian Fainelli
Cc: Sergei Shtylyov, Andrew Lunn, Frank Rowand, netdev,
devicetree@vger.kernel.org
In-Reply-To: <f9af35a3-bb53-c554-eb6e-93cf6c24cb29@gmail.com>
On Mon, Aug 7, 2017 at 1:01 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 08/07/2017 09:18 AM, Sergei Shtylyov wrote:
>> Hello!
>>
>> On 08/07/2017 05:18 PM, Rob Herring wrote:
>>
>>>> The "fixed-link" prop support predated of_property_read_u32_array(), so
>>>> basically had to open-code it. Using the modern API saves 24 bytes of
>>>> the
>>>> object code (ARM gcc 4.8.5); the only behavior change would be that the
>>>> prop length check is now less strict (however the strict pre-check done
>>>> in of_phy_is_fixed_link() is left intact anyway)...
>>>>
>>>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>>>
>>>> ---
>>>> The patch is against the 'dt/next' branch of Rob Herring's
>>>> 'linux-git' repo
>>>> plus the previously posted patch killing the useless local variable in
>>>> of_phy_register_fixed_link().
>>>
>>> It shouldn't depend on anything in my tree and David normally takes
>>> of_mdio.c changes.
>>
>> MAINTAINERS still only point at the DT repo, perhaps it should be
>> updated?
>
> More or less done with this (minus the repo part):
>
> http://patchwork.ozlabs.org/patch/795887/
Really I'd like to see this fixed by moving of_mdio.c and of_net.c to
drivers/net/ as we've done for all other subsystems.
Rob
^ permalink raw reply
* [PATCH net-next v2 2/2] bpf: Extend check_uarg_tail_zero() checks
From: Mickaël Salaün @ 2017-08-07 18:45 UTC (permalink / raw)
To: linux-kernel
Cc: Mickaël Salaün, Alexei Starovoitov, Daniel Borkmann,
David S . Miller, Kees Cook, Martin KaFai Lau, netdev,
Alexei Starovoitov
In-Reply-To: <20170807184520.8130-1-mic@digikod.net>
The function check_uarg_tail_zero() was created from bpf(2) for
BPF_OBJ_GET_INFO_BY_FD without taking the access_ok() nor the PAGE_SIZE
checks. Make this checks more generally available while unlikely to be
triggered, extend the memory range check and add an explanation
including why the ToCToU should not be a security concern.
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Martin KaFai Lau <kafai@fb.com>
Link: https://lkml.kernel.org/r/CAGXu5j+vRGFvJZmjtAcT8Hi8B+Wz0e1b6VKYZHfQP_=DXzC4CQ@mail.gmail.com
---
kernel/bpf/syscall.c | 26 +++++++++++++++-----------
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index c653ee0bd162..fbe09a0cccf4 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -48,6 +48,15 @@ static const struct bpf_map_ops * const bpf_map_types[] = {
#undef BPF_MAP_TYPE
};
+/*
+ * If we're handed a bigger struct than we know of, ensure all the unknown bits
+ * are 0 - i.e. new user-space does not rely on any kernel feature extensions
+ * we don't know about yet.
+ *
+ * There is a ToCToU between this function call and the following
+ * copy_from_user() call. However, this is not a concern since this function is
+ * meant to be a future-proofing of bits.
+ */
static int check_uarg_tail_zero(void __user *uaddr,
size_t expected_size,
size_t actual_size)
@@ -57,6 +66,12 @@ static int check_uarg_tail_zero(void __user *uaddr,
unsigned char val;
int err;
+ if (unlikely(actual_size > PAGE_SIZE)) /* silly large */
+ return -E2BIG;
+
+ if (unlikely(!access_ok(VERIFY_READ, uaddr, actual_size)))
+ return -EFAULT;
+
if (actual_size <= expected_size)
return 0;
@@ -1393,17 +1408,6 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, siz
if (!capable(CAP_SYS_ADMIN) && sysctl_unprivileged_bpf_disabled)
return -EPERM;
- if (!access_ok(VERIFY_READ, uattr, 1))
- return -EFAULT;
-
- if (size > PAGE_SIZE) /* silly large */
- return -E2BIG;
-
- /* If we're handed a bigger struct than we know of,
- * ensure all the unknown bits are 0 - i.e. new
- * user-space does not rely on any kernel feature
- * extensions we dont know about yet.
- */
err = check_uarg_tail_zero(uattr, sizeof(attr), size);
if (err)
return err;
--
2.13.3
^ permalink raw reply related
* [PATCH net-next v2 1/2] bpf: Move check_uarg_tail_zero() upward
From: Mickaël Salaün @ 2017-08-07 18:45 UTC (permalink / raw)
To: linux-kernel
Cc: Mickaël Salaün, Alexei Starovoitov, Daniel Borkmann,
David S . Miller, Kees Cook, Martin KaFai Lau, netdev,
Alexei Starovoitov
The function check_uarg_tail_zero() may be useful for other part of the
code in the syscall.c file. Move this function at the beginning of the
file.
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: David S. Miller <davem@davemloft.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: Martin KaFai Lau <kafai@fb.com>
---
This is needed for the Landlock patch series. :)
---
kernel/bpf/syscall.c | 52 ++++++++++++++++++++++++++--------------------------
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 6c772adabad2..c653ee0bd162 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -48,6 +48,32 @@ static const struct bpf_map_ops * const bpf_map_types[] = {
#undef BPF_MAP_TYPE
};
+static int check_uarg_tail_zero(void __user *uaddr,
+ size_t expected_size,
+ size_t actual_size)
+{
+ unsigned char __user *addr;
+ unsigned char __user *end;
+ unsigned char val;
+ int err;
+
+ if (actual_size <= expected_size)
+ return 0;
+
+ addr = uaddr + expected_size;
+ end = uaddr + actual_size;
+
+ for (; addr < end; addr++) {
+ err = get_user(val, addr);
+ if (err)
+ return err;
+ if (val)
+ return -E2BIG;
+ }
+
+ return 0;
+}
+
static struct bpf_map *find_and_alloc_map(union bpf_attr *attr)
{
struct bpf_map *map;
@@ -1246,32 +1272,6 @@ static int bpf_map_get_fd_by_id(const union bpf_attr *attr)
return fd;
}
-static int check_uarg_tail_zero(void __user *uaddr,
- size_t expected_size,
- size_t actual_size)
-{
- unsigned char __user *addr;
- unsigned char __user *end;
- unsigned char val;
- int err;
-
- if (actual_size <= expected_size)
- return 0;
-
- addr = uaddr + expected_size;
- end = uaddr + actual_size;
-
- for (; addr < end; addr++) {
- err = get_user(val, addr);
- if (err)
- return err;
- if (val)
- return -E2BIG;
- }
-
- return 0;
-}
-
static int bpf_prog_get_info_by_fd(struct bpf_prog *prog,
const union bpf_attr *attr,
union bpf_attr __user *uattr)
--
2.13.3
^ permalink raw reply related
* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
From: David Miller @ 2017-08-07 18:45 UTC (permalink / raw)
To: dsahern; +Cc: stephen, simon.horman, daniel, phil, netdev
In-Reply-To: <bd0ad410-9b64-6f1b-6f78-08f6e801628b@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Mon, 7 Aug 2017 12:09:31 -0600
> On 8/7/17 12:06 PM, Stephen Hemminger wrote:
>>> Does not work. Seems like you pushed the RFC commit which was known to
>>> be incomplete.
>>
>> Patches welcome.
>
> What exists does not even compile. Patches will be sent once you fix that.
Yeah seriously Stephen, you created this huge mess so the onus is really
on you to fix it up.
^ permalink raw reply
* Re: [PATCH v3 net-next 0/7] net: l3mdev: Support for sockets bound to enslaved device
From: David Ahern @ 2017-08-07 18:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20170807.113942.927598740175023982.davem@davemloft.net>
On 8/7/17 12:39 PM, David Miller wrote:
> Series applied, let's see if it builds this time :-)
I did an allyesconfig build before sending just to make sure, so our
mileage better not vary.
^ 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