* Re: [PATCH] 6lowpan: no need to check return value of debugfs_create functions
From: Marcel Holtmann @ 2019-07-06 10:52 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Alexander Aring, Jukka Rissanen, David S. Miller, linux-bluetooth,
linux-wpan, netdev
In-Reply-To: <20190614071423.GA18533@kroah.com>
Hi Greg,
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Because we don't care if debugfs works or not, this trickles back a bit
> so we can clean things up by making some functions return void instead
> of an error value that is never going to fail.
>
> Cc: Alexander Aring <alex.aring@gmail.com>
> Cc: Jukka Rissanen <jukka.rissanen@linux.intel.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: linux-bluetooth@vger.kernel.org
> Cc: linux-wpan@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> net/6lowpan/6lowpan_i.h | 16 ++-----
> net/6lowpan/core.c | 8 +---
> net/6lowpan/debugfs.c | 97 +++++++++++------------------------------
> 3 files changed, 32 insertions(+), 89 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v6 2/2] dt-bindings: net: bluetooth: Add device property firmware-name for QCA6174
From: Marcel Holtmann @ 2019-07-06 10:56 UTC (permalink / raw)
To: Rocky Liao
Cc: robh+dt, mark.rutland, Johan Hedberg, thierry.escande, netdev,
devicetree, linux-kernel, linux-bluetooth, linux-arm-msm,
bgodavar, c-hbandi
In-Reply-To: <1559814055-13872-1-git-send-email-rjliao@codeaurora.org>
Hi Rocky,
> This patch adds an optional device property "firmware-name" to allow the
> driver to load customized nvm firmware file based on this property.
>
> Signed-off-by: Rocky Liao <rjliao@codeaurora.org>
> ---
> Changes in v6:
> * Added read firmware-name property for both QCA6174 and WCN399X
> ---
> Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt | 4 ++++
> 1 file changed, 4 insertions(+)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: hidp: NUL terminate a string in the compat ioctl
From: Marcel Holtmann @ 2019-07-06 11:08 UTC (permalink / raw)
To: Dan Carpenter
Cc: Johan Hedberg, Mark Salyzyn, Andrea Parri, linux-bluetooth,
netdev, Allen Pais, Young Xiao
In-Reply-To: <20190516182400.GA8270@mwanda>
Hi Dan,
> This change is similar to commit a1616a5ac99e ("Bluetooth: hidp: fix
> buffer overflow") but for the compat ioctl. We take a string from the
> user and forgot to ensure that it's NUL terminated.
>
> I have also changed the strncpy() in to strscpy() in hidp_setup_hid().
> The difference is the strncpy() doesn't necessarily NUL terminate the
> destination string. Either change would fix the problem but it's nice
> to take a belt and suspenders approach and do both.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> net/bluetooth/hidp/core.c | 2 +-
> net/bluetooth/hidp/sock.c | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [PATCH net-next v2 0/3] net: Multipath hashing on inner L3
From: Stephen Suryaputra @ 2019-07-06 14:55 UTC (permalink / raw)
To: netdev; +Cc: idosch, nikolay, dsahern, Stephen Suryaputra
This series extends commit 363887a2cdfe ("ipv4: Support multipath
hashing on inner IP pkts for GRE tunnel") to include support when the
outer L3 is IPv6 and to consider the case where the inner L3 is
different version from the outer L3, such as IPv6 tunneled by IPv4 GRE
or vice versa. It also includes kselftest scripts to test the use cases.
v2: Clarify the commit messages in the commits in this series to use the
term tunneled by IPv4 GRE or by IPv6 GRE so that it's clear which
one is the inner and which one is the outer (per David Miller).
Stephen Suryaputra (3):
ipv4: Multipath hashing on inner L3 needs to consider inner IPv6 pkts
ipv6: Support multipath hashing on inner IP pkts
selftests: forwarding: Test multipath hashing on inner IP pkts for GRE
tunnel
Documentation/networking/ip-sysctl.txt | 1 +
net/ipv4/route.c | 21 +-
net/ipv6/route.c | 36 +++
.../net/forwarding/gre_inner_v4_multipath.sh | 305 +++++++++++++++++
.../net/forwarding/gre_inner_v6_multipath.sh | 306 ++++++++++++++++++
.../forwarding/ip6gre_inner_v4_multipath.sh | 304 +++++++++++++++++
.../forwarding/ip6gre_inner_v6_multipath.sh | 305 +++++++++++++++++
7 files changed, 1274 insertions(+), 4 deletions(-)
create mode 100755 tools/testing/selftests/net/forwarding/gre_inner_v4_multipath.sh
create mode 100755 tools/testing/selftests/net/forwarding/gre_inner_v6_multipath.sh
create mode 100755 tools/testing/selftests/net/forwarding/ip6gre_inner_v4_multipath.sh
create mode 100755 tools/testing/selftests/net/forwarding/ip6gre_inner_v6_multipath.sh
--
2.17.1
^ permalink raw reply
* [PATCH net-next v2 1/3] ipv4: Multipath hashing on inner L3 needs to consider inner IPv6 pkts
From: Stephen Suryaputra @ 2019-07-06 14:55 UTC (permalink / raw)
To: netdev; +Cc: idosch, nikolay, dsahern, Stephen Suryaputra
In-Reply-To: <20190706145519.13488-1-ssuryaextr@gmail.com>
Commit 363887a2cdfe ("ipv4: Support multipath hashing on inner IP pkts
for GRE tunnel") supports multipath policy value of 2, Layer 3 or inner
Layer 3 if present, but it only considers inner IPv4. There is a use
case of IPv6 is tunneled by IPv4 GRE, thus add the ability to hash on
inner IPv6 addresses.
Fixes: 363887a2cdfe ("ipv4: Support multipath hashing on inner IP pkts for GRE tunnel")
Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
---
net/ipv4/route.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index dc1f510a7c81..abaa7f9371e5 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1964,17 +1964,30 @@ int fib_multipath_hash(const struct net *net, const struct flowi4 *fl4,
break;
case 2:
memset(&hash_keys, 0, sizeof(hash_keys));
- hash_keys.control.addr_type = FLOW_DISSECTOR_KEY_IPV4_ADDRS;
/* skb is currently provided only when forwarding */
if (skb) {
struct flow_keys keys;
skb_flow_dissect_flow_keys(skb, &keys, 0);
-
- hash_keys.addrs.v4addrs.src = keys.addrs.v4addrs.src;
- hash_keys.addrs.v4addrs.dst = keys.addrs.v4addrs.dst;
+ /* Inner can be v4 or v6 */
+ if (keys.control.addr_type == FLOW_DISSECTOR_KEY_IPV4_ADDRS) {
+ hash_keys.control.addr_type = FLOW_DISSECTOR_KEY_IPV4_ADDRS;
+ hash_keys.addrs.v4addrs.src = keys.addrs.v4addrs.src;
+ hash_keys.addrs.v4addrs.dst = keys.addrs.v4addrs.dst;
+ } else if (keys.control.addr_type == FLOW_DISSECTOR_KEY_IPV6_ADDRS) {
+ hash_keys.control.addr_type = FLOW_DISSECTOR_KEY_IPV6_ADDRS;
+ hash_keys.addrs.v6addrs.src = keys.addrs.v6addrs.src;
+ hash_keys.addrs.v6addrs.dst = keys.addrs.v6addrs.dst;
+ hash_keys.tags.flow_label = keys.tags.flow_label;
+ hash_keys.basic.ip_proto = keys.basic.ip_proto;
+ } else {
+ /* Same as case 0 */
+ hash_keys.control.addr_type = FLOW_DISSECTOR_KEY_IPV4_ADDRS;
+ ip_multipath_l3_keys(skb, &hash_keys);
+ }
} else {
/* Same as case 0 */
+ hash_keys.control.addr_type = FLOW_DISSECTOR_KEY_IPV4_ADDRS;
hash_keys.addrs.v4addrs.src = fl4->saddr;
hash_keys.addrs.v4addrs.dst = fl4->daddr;
}
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 2/3] ipv6: Support multipath hashing on inner IP pkts
From: Stephen Suryaputra @ 2019-07-06 14:55 UTC (permalink / raw)
To: netdev; +Cc: idosch, nikolay, dsahern, Stephen Suryaputra
In-Reply-To: <20190706145519.13488-1-ssuryaextr@gmail.com>
Make the same support as commit 363887a2cdfe ("ipv4: Support multipath
hashing on inner IP pkts for GRE tunnel") for outer IPv6. The hashing
considers both IPv4 and IPv6 pkts when they are tunneled by IPv6 GRE.
Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
---
Documentation/networking/ip-sysctl.txt | 1 +
net/ipv6/route.c | 36 ++++++++++++++++++++++++++
2 files changed, 37 insertions(+)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index f0e6d1f53485..48c79e78817b 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1473,6 +1473,7 @@ fib_multipath_hash_policy - INTEGER
Possible values:
0 - Layer 3 (source and destination addresses plus flow label)
1 - Layer 4 (standard 5-tuple)
+ 2 - Layer 3 or inner Layer 3 if present
anycast_src_echo_reply - BOOLEAN
Controls the use of anycast addresses as source addresses for ICMPv6
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 39361f57351a..4d2e6b31a8d6 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2370,6 +2370,42 @@ u32 rt6_multipath_hash(const struct net *net, const struct flowi6 *fl6,
hash_keys.basic.ip_proto = fl6->flowi6_proto;
}
break;
+ case 2:
+ memset(&hash_keys, 0, sizeof(hash_keys));
+ hash_keys.control.addr_type = FLOW_DISSECTOR_KEY_IPV6_ADDRS;
+ if (skb) {
+ struct flow_keys keys;
+
+ if (!flkeys) {
+ skb_flow_dissect_flow_keys(skb, &keys, 0);
+ flkeys = &keys;
+ }
+
+ /* Inner can be v4 or v6 */
+ if (flkeys->control.addr_type == FLOW_DISSECTOR_KEY_IPV4_ADDRS) {
+ hash_keys.control.addr_type = FLOW_DISSECTOR_KEY_IPV4_ADDRS;
+ hash_keys.addrs.v4addrs.src = flkeys->addrs.v4addrs.src;
+ hash_keys.addrs.v4addrs.dst = flkeys->addrs.v4addrs.dst;
+ } else if (flkeys->control.addr_type == FLOW_DISSECTOR_KEY_IPV6_ADDRS) {
+ hash_keys.control.addr_type = FLOW_DISSECTOR_KEY_IPV6_ADDRS;
+ hash_keys.addrs.v6addrs.src = flkeys->addrs.v6addrs.src;
+ hash_keys.addrs.v6addrs.dst = flkeys->addrs.v6addrs.dst;
+ hash_keys.tags.flow_label = flkeys->tags.flow_label;
+ hash_keys.basic.ip_proto = flkeys->basic.ip_proto;
+ } else {
+ /* Same as case 0 */
+ hash_keys.control.addr_type = FLOW_DISSECTOR_KEY_IPV6_ADDRS;
+ ip6_multipath_l3_keys(skb, &hash_keys, flkeys);
+ }
+ } else {
+ /* Same as case 0 */
+ hash_keys.control.addr_type = FLOW_DISSECTOR_KEY_IPV6_ADDRS;
+ hash_keys.addrs.v6addrs.src = fl6->saddr;
+ hash_keys.addrs.v6addrs.dst = fl6->daddr;
+ hash_keys.tags.flow_label = (__force u32)flowi6_get_flowlabel(fl6);
+ hash_keys.basic.ip_proto = fl6->flowi6_proto;
+ }
+ break;
}
mhash = flow_hash_from_keys(&hash_keys);
--
2.17.1
^ permalink raw reply related
* [PATCH net-next v2 3/3] selftests: forwarding: Test multipath hashing on inner IP pkts for GRE tunnel
From: Stephen Suryaputra @ 2019-07-06 14:55 UTC (permalink / raw)
To: netdev; +Cc: idosch, nikolay, dsahern, Stephen Suryaputra
In-Reply-To: <20190706145519.13488-1-ssuryaextr@gmail.com>
Add selftest scripts for multipath hashing on inner IP pkts when there
is a single GRE tunnel but there are multiple underlay routes to reach
the other end of the tunnel.
Four cases are covered in these scripts:
- IPv4 inner, IPv4 outer
- IPv6 inner, IPv4 outer
- IPv4 inner, IPv6 outer
- IPv6 inner, IPv6 outer
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
---
.../net/forwarding/gre_inner_v4_multipath.sh | 305 +++++++++++++++++
.../net/forwarding/gre_inner_v6_multipath.sh | 306 ++++++++++++++++++
.../forwarding/ip6gre_inner_v4_multipath.sh | 304 +++++++++++++++++
.../forwarding/ip6gre_inner_v6_multipath.sh | 305 +++++++++++++++++
4 files changed, 1220 insertions(+)
create mode 100755 tools/testing/selftests/net/forwarding/gre_inner_v4_multipath.sh
create mode 100755 tools/testing/selftests/net/forwarding/gre_inner_v6_multipath.sh
create mode 100755 tools/testing/selftests/net/forwarding/ip6gre_inner_v4_multipath.sh
create mode 100755 tools/testing/selftests/net/forwarding/ip6gre_inner_v6_multipath.sh
diff --git a/tools/testing/selftests/net/forwarding/gre_inner_v4_multipath.sh b/tools/testing/selftests/net/forwarding/gre_inner_v4_multipath.sh
new file mode 100755
index 000000000000..e4009f658003
--- /dev/null
+++ b/tools/testing/selftests/net/forwarding/gre_inner_v4_multipath.sh
@@ -0,0 +1,305 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# Test traffic distribution when there are multiple routes between an IPv4
+# GRE tunnel. The tunnel carries IPv4 traffic between multiple hosts.
+# Multiple routes are in the underlay network. With the default multipath
+# policy, SW2 will only look at the outer IP addresses, hence only a single
+# route would be used.
+#
+# +-------------------------+
+# | H1 |
+# | $h1 + |
+# | 192.0.3.{2-62}/24 | |
+# +-------------------|-----+
+# |
+# +-------------------|------------------------+
+# | SW1 | |
+# | $ol1 + |
+# | 192.0.3.1/24 |
+# | |
+# | + g1 (gre) |
+# | loc=192.0.2.65 |
+# | rem=192.0.2.66 --. |
+# | tos=inherit | |
+# | v |
+# | + $ul1 |
+# | | 192.0.2.129/28 |
+# +---------------------|----------------------+
+# |
+# +---------------------|----------------------+
+# | SW2 | |
+# | $ul21 + |
+# | 192.0.2.130/28 |
+# | | |
+# ! ________________|_____ |
+# | / \ |
+# | | | |
+# | + $ul22.111 (vlan) + $ul22.222 (vlan) |
+# | | 192.0.2.145/28 | 192.0.2.161/28 |
+# | | | |
+# +--|----------------------|------------------+
+# | |
+# +--|----------------------|------------------+
+# | | | |
+# | + $ul32.111 (vlan) + $ul32.222 (vlan) |
+# | | 192.0.2.146/28 | 192.0.2.162/28 |
+# | | | |
+# | \______________________/ |
+# | | |
+# | | |
+# | $ul31 + |
+# | 192.0.2.177/28 | SW3 |
+# +---------------------|----------------------+
+# |
+# +---------------------|----------------------+
+# | + $ul4 |
+# | ^ 192.0.2.178/28 |
+# | | |
+# | + g2 (gre) | |
+# | loc=192.0.2.66 | |
+# | rem=192.0.2.65 --' |
+# | tos=inherit |
+# | |
+# | $ol4 + |
+# | 192.0.4.1/24 | SW4 |
+# +--------------------|-----------------------+
+# |
+# +--------------------|---------+
+# | | |
+# | $h2 + |
+# | 192.0.4.{2-62}/24 H2 |
+# +------------------------------+
+
+ALL_TESTS="
+ ping_ipv4
+ multipath_ipv4
+"
+
+NUM_NETIFS=10
+source lib.sh
+
+h1_create()
+{
+ simple_if_init $h1 192.0.3.2/24
+ ip route add vrf v$h1 192.0.4.0/24 via 192.0.3.1
+}
+
+h1_destroy()
+{
+ ip route del vrf v$h1 192.0.4.0/24 via 192.0.3.1
+ simple_if_fini $h1 192.0.3.2/24
+}
+
+sw1_create()
+{
+ simple_if_init $ol1 192.0.3.1/24
+ __simple_if_init $ul1 v$ol1 192.0.2.129/28
+
+ tunnel_create g1 gre 192.0.2.65 192.0.2.66 tos inherit dev v$ol1
+ __simple_if_init g1 v$ol1 192.0.2.65/32
+ ip route add vrf v$ol1 192.0.2.66/32 via 192.0.2.130
+
+ ip route add vrf v$ol1 192.0.4.0/24 nexthop dev g1
+}
+
+sw1_destroy()
+{
+ ip route del vrf v$ol1 192.0.4.0/24
+
+ ip route del vrf v$ol1 192.0.2.66/32
+ __simple_if_fini g1 192.0.2.65/32
+ tunnel_destroy g1
+
+ __simple_if_fini $ul1 192.0.2.129/28
+ simple_if_fini $ol1 192.0.3.1/24
+}
+
+sw2_create()
+{
+ simple_if_init $ul21 192.0.2.130/28
+ __simple_if_init $ul22 v$ul21
+ vlan_create $ul22 111 v$ul21 192.0.2.145/28
+ vlan_create $ul22 222 v$ul21 192.0.2.161/28
+
+ ip route add vrf v$ul21 192.0.2.65/32 via 192.0.2.129
+ ip route add vrf v$ul21 192.0.2.66/32 \
+ nexthop via 192.0.2.146 \
+ nexthop via 192.0.2.162
+}
+
+sw2_destroy()
+{
+ ip route del vrf v$ul21 192.0.2.66/32
+ ip route del vrf v$ul21 192.0.2.65/32
+
+ vlan_destroy $ul22 222
+ vlan_destroy $ul22 111
+ __simple_if_fini $ul22
+ simple_if_fini $ul21 192.0.2.130/28
+}
+
+sw3_create()
+{
+ simple_if_init $ul31 192.0.2.177/28
+ __simple_if_init $ul32 v$ul31
+ vlan_create $ul32 111 v$ul31 192.0.2.146/28
+ vlan_create $ul32 222 v$ul31 192.0.2.162/28
+
+ ip route add vrf v$ul31 192.0.2.66/32 via 192.0.2.178
+ ip route add vrf v$ul31 192.0.2.65/32 \
+ nexthop via 192.0.2.145 \
+ nexthop via 192.0.2.161
+
+ tc qdisc add dev $ul32 clsact
+ tc filter add dev $ul32 ingress pref 111 prot 802.1Q \
+ flower vlan_id 111 action pass
+ tc filter add dev $ul32 ingress pref 222 prot 802.1Q \
+ flower vlan_id 222 action pass
+}
+
+sw3_destroy()
+{
+ tc qdisc del dev $ul32 clsact
+
+ ip route del vrf v$ul31 192.0.2.65/32
+ ip route del vrf v$ul31 192.0.2.66/32
+
+ vlan_destroy $ul32 222
+ vlan_destroy $ul32 111
+ __simple_if_fini $ul32
+ simple_if_fini $ul31 192.0.2.177/28
+}
+
+sw4_create()
+{
+ simple_if_init $ol4 192.0.4.1/24
+ __simple_if_init $ul4 v$ol4 192.0.2.178/28
+
+ tunnel_create g2 gre 192.0.2.66 192.0.2.65 tos inherit dev v$ol4
+ __simple_if_init g2 v$ol4 192.0.2.66/32
+ ip route add vrf v$ol4 192.0.2.65/32 via 192.0.2.177
+
+ ip route add vrf v$ol4 192.0.3.0/24 nexthop dev g2
+}
+
+sw4_destroy()
+{
+ ip route del vrf v$ol4 192.0.3.0/24
+
+ ip route del vrf v$ol4 192.0.2.65/32
+ __simple_if_fini g2 192.0.2.66/32
+ tunnel_destroy g2
+
+ __simple_if_fini $ul4 192.0.2.178/28
+ simple_if_fini $ol4 192.0.4.1/24
+}
+
+h2_create()
+{
+ simple_if_init $h2 192.0.4.2/24
+ ip route add vrf v$h2 192.0.3.0/24 via 192.0.4.1
+}
+
+h2_destroy()
+{
+ ip route del vrf v$h2 192.0.3.0/24 via 192.0.4.1
+ simple_if_fini $h2 192.0.4.2/24
+}
+
+setup_prepare()
+{
+ h1=${NETIFS[p1]}
+
+ ol1=${NETIFS[p2]}
+ ul1=${NETIFS[p3]}
+
+ ul21=${NETIFS[p4]}
+ ul22=${NETIFS[p5]}
+
+ ul32=${NETIFS[p6]}
+ ul31=${NETIFS[p7]}
+
+ ul4=${NETIFS[p8]}
+ ol4=${NETIFS[p9]}
+
+ h2=${NETIFS[p10]}
+
+ vrf_prepare
+ h1_create
+ sw1_create
+ sw2_create
+ sw3_create
+ sw4_create
+ h2_create
+
+ forwarding_enable
+}
+
+cleanup()
+{
+ pre_cleanup
+
+ forwarding_restore
+
+ h2_destroy
+ sw4_destroy
+ sw3_destroy
+ sw2_destroy
+ sw1_destroy
+ h1_destroy
+ vrf_cleanup
+}
+
+multipath4_test()
+{
+ local what=$1; shift
+ local weight1=$1; shift
+ local weight2=$1; shift
+
+ sysctl_set net.ipv4.fib_multipath_hash_policy 2
+ ip route replace vrf v$ul21 192.0.2.66/32 \
+ nexthop via 192.0.2.146 weight $weight1 \
+ nexthop via 192.0.2.162 weight $weight2
+
+ local t0_111=$(tc_rule_stats_get $ul32 111 ingress)
+ local t0_222=$(tc_rule_stats_get $ul32 222 ingress)
+
+ ip vrf exec v$h1 \
+ $MZ $h1 -q -p 64 -A "192.0.3.2-192.0.3.62" -B "192.0.4.2-192.0.4.62" \
+ -d 1msec -c 50 -t udp "sp=1024,dp=1024"
+ sleep 1
+
+ local t1_111=$(tc_rule_stats_get $ul32 111 ingress)
+ local t1_222=$(tc_rule_stats_get $ul32 222 ingress)
+
+ local d111=$((t1_111 - t0_111))
+ local d222=$((t1_222 - t0_222))
+ multipath_eval "$what" $weight1 $weight2 $d111 $d222
+
+ ip route replace vrf v$ul21 192.0.2.66/32 \
+ nexthop via 192.0.2.146 \
+ nexthop via 192.0.2.162
+ sysctl_restore net.ipv4.fib_multipath_hash_policy
+}
+
+ping_ipv4()
+{
+ ping_test $h1 192.0.4.2
+}
+
+multipath_ipv4()
+{
+ log_info "Running IPv4 over GRE over IPv4 multipath tests"
+ multipath4_test "ECMP" 1 1
+ multipath4_test "Weighted MP 2:1" 2 1
+ multipath4_test "Weighted MP 11:45" 11 45
+}
+
+trap cleanup EXIT
+
+setup_prepare
+setup_wait
+tests_run
+
+exit $EXIT_STATUS
diff --git a/tools/testing/selftests/net/forwarding/gre_inner_v6_multipath.sh b/tools/testing/selftests/net/forwarding/gre_inner_v6_multipath.sh
new file mode 100755
index 000000000000..e449475c4d3e
--- /dev/null
+++ b/tools/testing/selftests/net/forwarding/gre_inner_v6_multipath.sh
@@ -0,0 +1,306 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# Test traffic distribution when there are multiple routes between an IPv4
+# GRE tunnel. The tunnel carries IPv6 traffic between multiple hosts.
+# Multiple routes are in the underlay network. With the default multipath
+# policy, SW2 will only look at the outer IP addresses, hence only a single
+# route would be used.
+#
+# +-------------------------+
+# | H1 |
+# | $h1 + |
+# | 2001:db8:1::2/64 | |
+# +-------------------|-----+
+# |
+# +-------------------|------------------------+
+# | SW1 | |
+# | $ol1 + |
+# | 2001:db8:1::1/64 |
+# | |
+# | + g1 (gre) |
+# | loc=192.0.2.65 |
+# | rem=192.0.2.66 --. |
+# | tos=inherit | |
+# | v |
+# | + $ul1 |
+# | | 192.0.2.129/28 |
+# +---------------------|----------------------+
+# |
+# +---------------------|----------------------+
+# | SW2 | |
+# | $ul21 + |
+# | 192.0.2.130/28 |
+# | | |
+# ! ________________|_____ |
+# | / \ |
+# | | | |
+# | + $ul22.111 (vlan) + $ul22.222 (vlan) |
+# | | 192.0.2.145/28 | 192.0.2.161/28 |
+# | | | |
+# +--|----------------------|------------------+
+# | |
+# +--|----------------------|------------------+
+# | | | |
+# | + $ul32.111 (vlan) + $ul32.222 (vlan) |
+# | | 192.0.2.146/28 | 192.0.2.162/28 |
+# | | | |
+# | \______________________/ |
+# | | |
+# | | |
+# | $ul31 + |
+# | 192.0.2.177/28 | SW3 |
+# +---------------------|----------------------+
+# |
+# +---------------------|----------------------+
+# | + $ul4 |
+# | ^ 192.0.2.178/28 |
+# | | |
+# | + g2 (gre) | |
+# | loc=192.0.2.66 | |
+# | rem=192.0.2.65 --' |
+# | tos=inherit |
+# | |
+# | $ol4 + |
+# | 2001:db8:2::1/64 | SW4 |
+# +--------------------|-----------------------+
+# |
+# +--------------------|---------+
+# | | |
+# | $h2 + |
+# | 2001:db8:2::2/64 H2 |
+# +------------------------------+
+
+ALL_TESTS="
+ ping_ipv6
+ multipath_ipv6
+"
+
+NUM_NETIFS=10
+source lib.sh
+
+h1_create()
+{
+ simple_if_init $h1 2001:db8:1::2/64
+ ip -6 route add vrf v$h1 2001:db8:2::/64 via 2001:db8:1::1
+}
+
+h1_destroy()
+{
+ ip -6 route del vrf v$h1 2001:db8:2::/64 via 2001:db8:1::1
+ simple_if_fini $h1 2001:db8:1::2/64
+}
+
+sw1_create()
+{
+ simple_if_init $ol1 2001:db8:1::1/64
+ __simple_if_init $ul1 v$ol1 192.0.2.129/28
+
+ tunnel_create g1 gre 192.0.2.65 192.0.2.66 tos inherit dev v$ol1
+ __simple_if_init g1 v$ol1 192.0.2.65/32
+ ip route add vrf v$ol1 192.0.2.66/32 via 192.0.2.130
+
+ ip -6 route add vrf v$ol1 2001:db8:2::/64 dev g1
+}
+
+sw1_destroy()
+{
+ ip -6 route del vrf v$ol1 2001:db8:2::/64
+
+ ip route del vrf v$ol1 192.0.2.66/32
+ __simple_if_fini g1 192.0.2.65/32
+ tunnel_destroy g1
+
+ __simple_if_fini $ul1 192.0.2.129/28
+ simple_if_fini $ol1 2001:db8:1::1/64
+}
+
+sw2_create()
+{
+ simple_if_init $ul21 192.0.2.130/28
+ __simple_if_init $ul22 v$ul21
+ vlan_create $ul22 111 v$ul21 192.0.2.145/28
+ vlan_create $ul22 222 v$ul21 192.0.2.161/28
+
+ ip route add vrf v$ul21 192.0.2.65/32 via 192.0.2.129
+ ip route add vrf v$ul21 192.0.2.66/32 \
+ nexthop via 192.0.2.146 \
+ nexthop via 192.0.2.162
+}
+
+sw2_destroy()
+{
+ ip route del vrf v$ul21 192.0.2.66/32
+ ip route del vrf v$ul21 192.0.2.65/32
+
+ vlan_destroy $ul22 222
+ vlan_destroy $ul22 111
+ __simple_if_fini $ul22
+ simple_if_fini $ul21 192.0.2.130/28
+}
+
+sw3_create()
+{
+ simple_if_init $ul31 192.0.2.177/28
+ __simple_if_init $ul32 v$ul31
+ vlan_create $ul32 111 v$ul31 192.0.2.146/28
+ vlan_create $ul32 222 v$ul31 192.0.2.162/28
+
+ ip route add vrf v$ul31 192.0.2.66/32 via 192.0.2.178
+ ip route add vrf v$ul31 192.0.2.65/32 \
+ nexthop via 192.0.2.145 \
+ nexthop via 192.0.2.161
+
+ tc qdisc add dev $ul32 clsact
+ tc filter add dev $ul32 ingress pref 111 prot 802.1Q \
+ flower vlan_id 111 action pass
+ tc filter add dev $ul32 ingress pref 222 prot 802.1Q \
+ flower vlan_id 222 action pass
+}
+
+sw3_destroy()
+{
+ tc qdisc del dev $ul32 clsact
+
+ ip route del vrf v$ul31 192.0.2.65/32
+ ip route del vrf v$ul31 192.0.2.66/32
+
+ vlan_destroy $ul32 222
+ vlan_destroy $ul32 111
+ __simple_if_fini $ul32
+ simple_if_fini $ul31 192.0.2.177/28
+}
+
+sw4_create()
+{
+ simple_if_init $ol4 2001:db8:2::1/64
+ __simple_if_init $ul4 v$ol4 192.0.2.178/28
+
+ tunnel_create g2 gre 192.0.2.66 192.0.2.65 tos inherit dev v$ol4
+ __simple_if_init g2 v$ol4 192.0.2.66/32
+ ip route add vrf v$ol4 192.0.2.65/32 via 192.0.2.177
+
+ ip -6 route add vrf v$ol4 2001:db8:1::/64 dev g2
+}
+
+sw4_destroy()
+{
+ ip -6 route del vrf v$ol4 2001:db8:1::/64
+
+ ip route del vrf v$ol4 192.0.2.65/32
+ __simple_if_fini g2 192.0.2.66/32
+ tunnel_destroy g2
+
+ __simple_if_fini $ul4 192.0.2.178/28
+ simple_if_fini $ol4 2001:db8:2::1/64
+}
+
+h2_create()
+{
+ simple_if_init $h2 2001:db8:2::2/64
+ ip -6 route add vrf v$h2 2001:db8:1::/64 via 2001:db8:2::1
+}
+
+h2_destroy()
+{
+ ip -6 route del vrf v$h2 2001:db8:1::/64 via 2001:db8:2::1
+ simple_if_fini $h2 2001:db8:2::2/64
+}
+
+setup_prepare()
+{
+ h1=${NETIFS[p1]}
+
+ ol1=${NETIFS[p2]}
+ ul1=${NETIFS[p3]}
+
+ ul21=${NETIFS[p4]}
+ ul22=${NETIFS[p5]}
+
+ ul32=${NETIFS[p6]}
+ ul31=${NETIFS[p7]}
+
+ ul4=${NETIFS[p8]}
+ ol4=${NETIFS[p9]}
+
+ h2=${NETIFS[p10]}
+
+ vrf_prepare
+ h1_create
+ sw1_create
+ sw2_create
+ sw3_create
+ sw4_create
+ h2_create
+
+ forwarding_enable
+}
+
+cleanup()
+{
+ pre_cleanup
+
+ forwarding_restore
+
+ h2_destroy
+ sw4_destroy
+ sw3_destroy
+ sw2_destroy
+ sw1_destroy
+ h1_destroy
+ vrf_cleanup
+}
+
+multipath6_test()
+{
+ local what=$1; shift
+ local weight1=$1; shift
+ local weight2=$1; shift
+
+ sysctl_set net.ipv4.fib_multipath_hash_policy 2
+ ip route replace vrf v$ul21 192.0.2.66/32 \
+ nexthop via 192.0.2.146 weight $weight1 \
+ nexthop via 192.0.2.162 weight $weight2
+
+ local t0_111=$(tc_rule_stats_get $ul32 111 ingress)
+ local t0_222=$(tc_rule_stats_get $ul32 222 ingress)
+
+ ip vrf exec v$h1 \
+ $MZ $h1 -6 -q -p 64 -A "2001:db8:1::2-2001:db8:1::1e" \
+ -B "2001:db8:2::2-2001:db8:2::1e" \
+ -d 1msec -c 50 -t udp "sp=1024,dp=1024"
+ sleep 1
+
+ local t1_111=$(tc_rule_stats_get $ul32 111 ingress)
+ local t1_222=$(tc_rule_stats_get $ul32 222 ingress)
+
+ local d111=$((t1_111 - t0_111))
+ local d222=$((t1_222 - t0_222))
+ multipath_eval "$what" $weight1 $weight2 $d111 $d222
+
+ ip route replace vrf v$ul21 192.0.2.66/32 \
+ nexthop via 192.0.2.146 \
+ nexthop via 192.0.2.162
+ sysctl_restore net.ipv4.fib_multipath_hash_policy
+}
+
+ping_ipv6()
+{
+ ping_test $h1 2001:db8:2::2
+}
+
+multipath_ipv6()
+{
+ log_info "Running IPv6 over GRE over IPv4 multipath tests"
+ multipath6_test "ECMP" 1 1
+ multipath6_test "Weighted MP 2:1" 2 1
+ multipath6_test "Weighted MP 11:45" 11 45
+}
+
+trap cleanup EXIT
+
+setup_prepare
+setup_wait
+tests_run
+
+exit $EXIT_STATUS
diff --git a/tools/testing/selftests/net/forwarding/ip6gre_inner_v4_multipath.sh b/tools/testing/selftests/net/forwarding/ip6gre_inner_v4_multipath.sh
new file mode 100755
index 000000000000..a257979d3fc5
--- /dev/null
+++ b/tools/testing/selftests/net/forwarding/ip6gre_inner_v4_multipath.sh
@@ -0,0 +1,304 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# Test traffic distribution when there are multiple routes between an IPv6
+# GRE tunnel. The tunnel carries IPv4 traffic between multiple hosts.
+# Multiple routes are in the underlay network. With the default multipath
+# policy, SW2 will only look at the outer IP addresses, hence only a single
+# route would be used.
+#
+# +-------------------------+
+# | H1 |
+# | $h1 + |
+# | 192.0.3.{2-62}/24 | |
+# +-------------------|-----+
+# |
+# +-------------------|-------------------------+
+# | SW1 | |
+# | $ol1 + |
+# | 192.0.3.1/24 |
+# | |
+# | + g1 (gre) |
+# | loc=2001:db8:40::1 |
+# | rem=2001:db8:40::2 --. |
+# | tos=inherit | |
+# | v |
+# | + $ul1 |
+# | | 2001:db8:80::1/64 |
+# +-------------------------|-------------------+
+# |
+# +-------------------------|-------------------+
+# | SW2 | |
+# | $ul21 + |
+# | 2001:db8:80::2/64 |
+# | | |
+# ! ________________|_____ |
+# | / \ |
+# | | | |
+# | + $ul22.111 (vlan) + $ul22.222 (vlan) |
+# | | 2001:db8:81::1/64 | 2001:db8:82::1/64 |
+# | | | |
+# +--|----------------------|-------------------+
+# | |
+# +--|----------------------|-------------------+
+# | | | |
+# | + $ul32.111 (vlan) + $ul32.222 (vlan) |
+# | | 2001:db8:81::2/64 | 2001:db8:82::2/64 |
+# | | | |
+# | \______________________/ |
+# | | |
+# | | |
+# | $ul31 + |
+# | 2001:db8:83::2/64 | SW3 |
+# +-------------------------|-------------------+
+# |
+# +-------------------------|-------------------+
+# | + $ul4 |
+# | ^ 2001:db8:83::1/64 |
+# | + g2 (gre) | |
+# | loc=2001:db8:40::2 | |
+# | rem=2001:db8:40::1 --' |
+# | tos=inherit |
+# | |
+# | $ol4 + |
+# | 192.0.4.1/24 | SW4 |
+# +--------------------|------------------------+
+# |
+# +--------------------|---------+
+# | | |
+# | $h2 + |
+# | 192.0.4.{2-62}/24 H2 |
+# +------------------------------+
+
+ALL_TESTS="
+ ping_ipv4
+ multipath_ipv4
+"
+
+NUM_NETIFS=10
+source lib.sh
+
+h1_create()
+{
+ simple_if_init $h1 192.0.3.2/24
+ ip route add vrf v$h1 192.0.4.0/24 via 192.0.3.1
+}
+
+h1_destroy()
+{
+ ip route del vrf v$h1 192.0.4.0/24 via 192.0.3.1
+ simple_if_fini $h1 192.0.3.2/24
+}
+
+sw1_create()
+{
+ simple_if_init $ol1 192.0.3.1/24
+ __simple_if_init $ul1 v$ol1 2001:db8:80::1/64
+
+ tunnel_create g1 ip6gre 2001:db8:40::1 2001:db8:40::2 tos inherit dev v$ol1
+ __simple_if_init g1 v$ol1 2001:db8:40::1/128
+ ip -6 route add vrf v$ol1 2001:db8:40::2/128 via 2001:db8:80::2
+
+ ip route add vrf v$ol1 192.0.4.0/24 nexthop dev g1
+}
+
+sw1_destroy()
+{
+ ip route del vrf v$ol1 192.0.4.0/24
+
+ ip -6 route del vrf v$ol1 2001:db8:40::2/128
+ __simple_if_fini g1 2001:db8:40::1/128
+ tunnel_destroy g1
+
+ __simple_if_fini $ul1 2001:db8:80::1/64
+ simple_if_fini $ol1 192.0.3.1/24
+}
+
+sw2_create()
+{
+ simple_if_init $ul21 2001:db8:80::2/64
+ __simple_if_init $ul22 v$ul21
+ vlan_create $ul22 111 v$ul21 2001:db8:81::1/64
+ vlan_create $ul22 222 v$ul21 2001:db8:82::1/64
+
+ ip -6 route add vrf v$ul21 2001:db8:40::1/128 via 2001:db8:80::1
+ ip -6 route add vrf v$ul21 2001:db8:40::2/128 \
+ nexthop via 2001:db8:81::2 \
+ nexthop via 2001:db8:82::2
+}
+
+sw2_destroy()
+{
+ ip -6 route del vrf v$ul21 2001:db8:40::2/128
+ ip -6 route del vrf v$ul21 2001:db8:40::1/128
+
+ vlan_destroy $ul22 222
+ vlan_destroy $ul22 111
+ __simple_if_fini $ul22
+ simple_if_fini $ul21 2001:db8:80::2/64
+}
+
+sw3_create()
+{
+ simple_if_init $ul31 2001:db8:83::2/64
+ __simple_if_init $ul32 v$ul31
+ vlan_create $ul32 111 v$ul31 2001:db8:81::2/64
+ vlan_create $ul32 222 v$ul31 2001:db8:82::2/64
+
+ ip -6 route add vrf v$ul31 2001:db8:40::2/128 via 2001:db8:83::1
+ ip -6 route add vrf v$ul31 2001:db8:40::1/128 \
+ nexthop via 2001:db8:81::1 \
+ nexthop via 2001:db8:82::1
+
+ tc qdisc add dev $ul32 clsact
+ tc filter add dev $ul32 ingress pref 111 prot 802.1Q \
+ flower vlan_id 111 action pass
+ tc filter add dev $ul32 ingress pref 222 prot 802.1Q \
+ flower vlan_id 222 action pass
+}
+
+sw3_destroy()
+{
+ tc qdisc del dev $ul32 clsact
+
+ ip -6 route del vrf v$ul31 2001:db8:40::1/128
+ ip -6 route del vrf v$ul31 2001:db8:40::2/128
+
+ vlan_destroy $ul32 222
+ vlan_destroy $ul32 111
+ __simple_if_fini $ul32
+ simple_if_fini $ul31 2001:Db8:83::2/64
+}
+
+sw4_create()
+{
+ simple_if_init $ol4 192.0.4.1/24
+ __simple_if_init $ul4 v$ol4 2001:db8:83::1/64
+
+ tunnel_create g2 ip6gre 2001:db8:40::2 2001:db8:40::1 tos inherit dev v$ol4
+ __simple_if_init g2 v$ol4 2001:db8:40::2/128
+ ip -6 route add vrf v$ol4 2001:db8:40::1/128 via 2001:db8:83::2
+
+ ip route add vrf v$ol4 192.0.3.0/24 nexthop dev g2
+}
+
+sw4_destroy()
+{
+ ip route del vrf v$ol4 192.0.3.0/24
+
+ ip -6 route del vrf v$ol4 2001:db8:40::1/128
+ __simple_if_fini g2 2001:db8:40::2/128
+ tunnel_destroy g2
+
+ __simple_if_fini $ul4 2001:db8:83::1/64
+ simple_if_fini $ol4 192.0.4.1/24
+}
+
+h2_create()
+{
+ simple_if_init $h2 192.0.4.2/24
+ ip route add vrf v$h2 192.0.3.0/24 via 192.0.4.1
+}
+
+h2_destroy()
+{
+ ip route del vrf v$h2 192.0.3.0/24 via 192.0.4.1
+ simple_if_fini $h2 192.0.4.2/24
+}
+
+setup_prepare()
+{
+ h1=${NETIFS[p1]}
+
+ ol1=${NETIFS[p2]}
+ ul1=${NETIFS[p3]}
+
+ ul21=${NETIFS[p4]}
+ ul22=${NETIFS[p5]}
+
+ ul32=${NETIFS[p6]}
+ ul31=${NETIFS[p7]}
+
+ ul4=${NETIFS[p8]}
+ ol4=${NETIFS[p9]}
+
+ h2=${NETIFS[p10]}
+
+ vrf_prepare
+ h1_create
+ sw1_create
+ sw2_create
+ sw3_create
+ sw4_create
+ h2_create
+
+ forwarding_enable
+}
+
+cleanup()
+{
+ pre_cleanup
+
+ forwarding_restore
+
+ h2_destroy
+ sw4_destroy
+ sw3_destroy
+ sw2_destroy
+ sw1_destroy
+ h1_destroy
+ vrf_cleanup
+}
+
+multipath4_test()
+{
+ local what=$1; shift
+ local weight1=$1; shift
+ local weight2=$1; shift
+
+ sysctl_set net.ipv6.fib_multipath_hash_policy 2
+ ip route replace vrf v$ul21 2001:db8:40::2/128 \
+ nexthop via 2001:db8:81::2 weight $weight1 \
+ nexthop via 2001:db8:82::2 weight $weight2
+
+ local t0_111=$(tc_rule_stats_get $ul32 111 ingress)
+ local t0_222=$(tc_rule_stats_get $ul32 222 ingress)
+
+ ip vrf exec v$h1 \
+ $MZ $h1 -q -p 64 -A "192.0.3.2-192.0.3.62" -B "192.0.4.2-192.0.4.62" \
+ -d 1msec -c 50 -t udp "sp=1024,dp=1024"
+ sleep 1
+
+ local t1_111=$(tc_rule_stats_get $ul32 111 ingress)
+ local t1_222=$(tc_rule_stats_get $ul32 222 ingress)
+
+ local d111=$((t1_111 - t0_111))
+ local d222=$((t1_222 - t0_222))
+ multipath_eval "$what" $weight1 $weight2 $d111 $d222
+
+ ip route replace vrf v$ul21 2001:db8:40::2/128 \
+ nexthop via 2001:db8:81::2 \
+ nexthop via 2001:db8:82::2
+ sysctl_restore net.ipv6.fib_multipath_hash_policy
+}
+
+ping_ipv4()
+{
+ ping_test $h1 192.0.4.2
+}
+
+multipath_ipv4()
+{
+ log_info "Running IPv4 over GRE over IPv6 multipath tests"
+ multipath4_test "ECMP" 1 1
+ multipath4_test "Weighted MP 2:1" 2 1
+ multipath4_test "Weighted MP 11:45" 11 45
+}
+
+trap cleanup EXIT
+
+setup_prepare
+setup_wait
+tests_run
+
+exit $EXIT_STATUS
diff --git a/tools/testing/selftests/net/forwarding/ip6gre_inner_v6_multipath.sh b/tools/testing/selftests/net/forwarding/ip6gre_inner_v6_multipath.sh
new file mode 100755
index 000000000000..d208f5243ade
--- /dev/null
+++ b/tools/testing/selftests/net/forwarding/ip6gre_inner_v6_multipath.sh
@@ -0,0 +1,305 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# Test traffic distribution when there are multiple routes between an IPv6
+# GRE tunnel. The tunnel carries IPv6 traffic between multiple hosts.
+# Multiple routes are in the underlay network. With the default multipath
+# policy, SW2 will only look at the outer IP addresses, hence only a single
+# route would be used.
+#
+# +-------------------------+
+# | H1 |
+# | $h1 + |
+# | 2001:db8:1::2/64 | |
+# +-------------------|-----+
+# |
+# +-------------------|-------------------------+
+# | SW1 | |
+# | $ol1 + |
+# | 2001:db8:1::1/64 |
+# | |
+# | + g1 (gre) |
+# | loc=2001:db8:40::1 |
+# | rem=2001:db8:40::2 --. |
+# | tos=inherit | |
+# | v |
+# | + $ul1 |
+# | | 2001:db8:80::1/64 |
+# +-------------------------|-------------------+
+# |
+# +-------------------------|-------------------+
+# | SW2 | |
+# | $ul21 + |
+# | 2001:db8:80::2/64 |
+# | | |
+# ! ________________|_____ |
+# | / \ |
+# | | | |
+# | + $ul22.111 (vlan) + $ul22.222 (vlan) |
+# | | 2001:db8:81::1/64 | 2001:db8:82::1/64 |
+# | | | |
+# +--|----------------------|-------------------+
+# | |
+# +--|----------------------|-------------------+
+# | | | |
+# | + $ul32.111 (vlan) + $ul32.222 (vlan) |
+# | | 2001:db8:81::2/64 | 2001:db8:82::2/64 |
+# | | | |
+# | \______________________/ |
+# | | |
+# | | |
+# | $ul31 + |
+# | 2001:db8:83::2/64 | SW3 |
+# +-------------------------|-------------------+
+# |
+# +-------------------------|-------------------+
+# | + $ul4 |
+# | ^ 2001:db8:83::1/64 |
+# | + g2 (gre) | |
+# | loc=2001:db8:40::2 | |
+# | rem=2001:db8:40::1 --' |
+# | tos=inherit |
+# | |
+# | $ol4 + |
+# | 2001:db8:2::1/64 | SW4 |
+# +--------------------|------------------------+
+# |
+# +--------------------|---------+
+# | | |
+# | $h2 + |
+# | 2001:db8:2::2/64 H2 |
+# +------------------------------+
+
+ALL_TESTS="
+ ping_ipv6
+ multipath_ipv6
+"
+
+NUM_NETIFS=10
+source lib.sh
+
+h1_create()
+{
+ simple_if_init $h1 2001:db8:1::2/64
+ ip -6 route add vrf v$h1 2001:db8:2::/64 via 2001:db8:1::1
+}
+
+h1_destroy()
+{
+ ip -6 route del vrf v$h1 2001:db8:2::/64 via 2001:db8:1::1
+ simple_if_fini $h1 2001:db8:1::2/64
+}
+
+sw1_create()
+{
+ simple_if_init $ol1 2001:db8:1::1/64
+ __simple_if_init $ul1 v$ol1 2001:db8:80::1/64
+
+ tunnel_create g1 ip6gre 2001:db8:40::1 2001:db8:40::2 tos inherit dev v$ol1
+ __simple_if_init g1 v$ol1 2001:db8:40::1/128
+ ip -6 route add vrf v$ol1 2001:db8:40::2/128 via 2001:db8:80::2
+
+ ip -6 route add vrf v$ol1 2001:db8:2::/64 dev g1
+}
+
+sw1_destroy()
+{
+ ip -6 route del vrf v$ol1 2001:db8:2::/64
+
+ ip -6 route del vrf v$ol1 2001:db8:40::2/128
+ __simple_if_fini g1 2001:db8:40::1/128
+ tunnel_destroy g1
+
+ __simple_if_fini $ul1 2001:db8:80::1/64
+ simple_if_fini $ol1 2001:db8:1::1/64
+}
+
+sw2_create()
+{
+ simple_if_init $ul21 2001:db8:80::2/64
+ __simple_if_init $ul22 v$ul21
+ vlan_create $ul22 111 v$ul21 2001:db8:81::1/64
+ vlan_create $ul22 222 v$ul21 2001:db8:82::1/64
+
+ ip -6 route add vrf v$ul21 2001:db8:40::1/128 via 2001:db8:80::1
+ ip -6 route add vrf v$ul21 2001:db8:40::2/128 \
+ nexthop via 2001:db8:81::2 \
+ nexthop via 2001:db8:82::2
+}
+
+sw2_destroy()
+{
+ ip -6 route del vrf v$ul21 2001:db8:40::2/128
+ ip -6 route del vrf v$ul21 2001:db8:40::1/128
+
+ vlan_destroy $ul22 222
+ vlan_destroy $ul22 111
+ __simple_if_fini $ul22
+ simple_if_fini $ul21 2001:db8:80::2/64
+}
+
+sw3_create()
+{
+ simple_if_init $ul31 2001:db8:83::2/64
+ __simple_if_init $ul32 v$ul31
+ vlan_create $ul32 111 v$ul31 2001:db8:81::2/64
+ vlan_create $ul32 222 v$ul31 2001:db8:82::2/64
+
+ ip -6 route add vrf v$ul31 2001:db8:40::2/128 via 2001:db8:83::1
+ ip -6 route add vrf v$ul31 2001:db8:40::1/128 \
+ nexthop via 2001:db8:81::1 \
+ nexthop via 2001:db8:82::1
+
+ tc qdisc add dev $ul32 clsact
+ tc filter add dev $ul32 ingress pref 111 prot 802.1Q \
+ flower vlan_id 111 action pass
+ tc filter add dev $ul32 ingress pref 222 prot 802.1Q \
+ flower vlan_id 222 action pass
+}
+
+sw3_destroy()
+{
+ tc qdisc del dev $ul32 clsact
+
+ ip -6 route del vrf v$ul31 2001:db8:40::1/128
+ ip -6 route del vrf v$ul31 2001:db8:40::2/128
+
+ vlan_destroy $ul32 222
+ vlan_destroy $ul32 111
+ __simple_if_fini $ul32
+ simple_if_fini $ul31 2001:Db8:83::2/64
+}
+
+sw4_create()
+{
+ simple_if_init $ol4 2001:db8:2::1/64
+ __simple_if_init $ul4 v$ol4 2001:db8:83::1/64
+
+ tunnel_create g2 ip6gre 2001:db8:40::2 2001:db8:40::1 tos inherit dev v$ol4
+ __simple_if_init g2 v$ol4 2001:db8:40::2/128
+ ip -6 route add vrf v$ol4 2001:db8:40::1/128 via 2001:db8:83::2
+
+ ip -6 route add vrf v$ol4 2001:db8:1::/64 dev g2
+}
+
+sw4_destroy()
+{
+ ip -6 route del vrf v$ol4 2001:db8:1::/64
+
+ ip -6 route del vrf v$ol4 2001:db8:40::1/128
+ __simple_if_fini g2 2001:db8:40::2/128
+ tunnel_destroy g2
+
+ __simple_if_fini $ul4 2001:db8:83::1/64
+ simple_if_fini $ol4 2001:db8:2::1/64
+}
+
+h2_create()
+{
+ simple_if_init $h2 2001:db8:2::2/64
+ ip -6 route add vrf v$h2 2001:db8:1::/64 via 2001:db8:2::1
+}
+
+h2_destroy()
+{
+ ip -6 route del vrf v$h2 2001:db8:1::/64 via 2001:db8:2::1
+ simple_if_fini $h2 2001:db8:2::2/64
+}
+
+setup_prepare()
+{
+ h1=${NETIFS[p1]}
+
+ ol1=${NETIFS[p2]}
+ ul1=${NETIFS[p3]}
+
+ ul21=${NETIFS[p4]}
+ ul22=${NETIFS[p5]}
+
+ ul32=${NETIFS[p6]}
+ ul31=${NETIFS[p7]}
+
+ ul4=${NETIFS[p8]}
+ ol4=${NETIFS[p9]}
+
+ h2=${NETIFS[p10]}
+
+ vrf_prepare
+ h1_create
+ sw1_create
+ sw2_create
+ sw3_create
+ sw4_create
+ h2_create
+
+ forwarding_enable
+}
+
+cleanup()
+{
+ pre_cleanup
+
+ forwarding_restore
+
+ h2_destroy
+ sw4_destroy
+ sw3_destroy
+ sw2_destroy
+ sw1_destroy
+ h1_destroy
+ vrf_cleanup
+}
+
+multipath6_test()
+{
+ local what=$1; shift
+ local weight1=$1; shift
+ local weight2=$1; shift
+
+ sysctl_set net.ipv6.fib_multipath_hash_policy 2
+ ip route replace vrf v$ul21 2001:db8:40::2/128 \
+ nexthop via 2001:db8:81::2 weight $weight1 \
+ nexthop via 2001:db8:82::2 weight $weight2
+
+ local t0_111=$(tc_rule_stats_get $ul32 111 ingress)
+ local t0_222=$(tc_rule_stats_get $ul32 222 ingress)
+
+ ip vrf exec v$h1 \
+ $MZ $h1 -6 -q -p 64 -A "2001:db8:1::2-2001:db8:1::1e" \
+ -B "2001:db8:2::2-2001:db8:2::1e" \
+ -d 1msec -c 50 -t udp "sp=1024,dp=1024"
+ sleep 1
+
+ local t1_111=$(tc_rule_stats_get $ul32 111 ingress)
+ local t1_222=$(tc_rule_stats_get $ul32 222 ingress)
+
+ local d111=$((t1_111 - t0_111))
+ local d222=$((t1_222 - t0_222))
+ multipath_eval "$what" $weight1 $weight2 $d111 $d222
+
+ ip route replace vrf v$ul21 2001:db8:40::2/128 \
+ nexthop via 2001:db8:81::2 \
+ nexthop via 2001:db8:82::2
+ sysctl_restore net.ipv6.fib_multipath_hash_policy
+}
+
+ping_ipv6()
+{
+ ping_test $h1 2001:db8:2::2
+}
+
+multipath_ipv6()
+{
+ log_info "Running IPv6 over GRE over IPv6 multipath tests"
+ multipath6_test "ECMP" 1 1
+ multipath6_test "Weighted MP 2:1" 2 1
+ multipath6_test "Weighted MP 11:45" 11 45
+}
+
+trap cleanup EXIT
+
+setup_prepare
+setup_wait
+tests_run
+
+exit $EXIT_STATUS
--
2.17.1
^ permalink raw reply related
* Re: INFO: rcu detected stall in ext4_write_checks
From: Theodore Ts'o @ 2019-07-06 15:02 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Dmitry Vyukov, syzbot, Andreas Dilger, David Miller, eladr,
Ido Schimmel, Jiri Pirko, John Stultz, linux-ext4, LKML, netdev,
syzkaller-bugs, Thomas Gleixner, Peter Zijlstra, Ingo Molnar
In-Reply-To: <20190706061631.GV26519@linux.ibm.com>
On Fri, Jul 05, 2019 at 11:16:31PM -0700, Paul E. McKenney wrote:
> I suppose RCU could take the dueling-banjos approach and use increasingly
> aggressive scheduler policies itself, up to and including SCHED_DEADLINE,
> until it started getting decent forward progress. However, that
> sounds like the something that just might have unintended consequences,
> particularly if other kernel subsystems were to also play similar
> games of dueling banjos.
So long as the RCU threads are well-behaved, using SCHED_DEADLINE
shouldn't have much of an impact on the system --- and the scheduling
parameters that you can specify on SCHED_DEADLINE allows you to
specify the worst-case impact on the system while also guaranteeing
that the SCHED_DEADLINE tasks will urn in the first place. After all,
that's the whole point of SCHED_DEADLINE.
So I wonder if the right approach is during the the first userspace
system call to shced_setattr to enable a (any) real-time priority
scheduler (SCHED_DEADLINE, SCHED_FIFO or SCHED_RR) on a userspace
thread, before that's allowed to proceed, the RCU kernel threads are
promoted to be SCHED_DEADLINE with appropriately set deadline
parameters. That way, a root user won't be able to shoot the system
in the foot, and since the vast majority of the time, there shouldn't
be any processes running with real-time priorities, we won't be
changing the behavior of a normal server system.
(I suspect there might be some audio applications that might try to
set real-time priorities, but for desktop systems, it's probably more
important that the system not tie its self into knots since the
average desktop user isn't going to be well equipped to debug the
problem.)
> Alternatively, is it possible to provide stricter admission control?
I think that's an orthogonal issue; better admission control would be
nice, but it looks to me that it's going to be fundamentally an issue
of tweaking hueristics, and a fool-proof solution that will protect
against all malicious userspace applications (including syzkaller) is
going to require solving the halting problem. So while it would be
nice to improve the admission control, I don't think that's a going to
be a general solution.
- Ted
^ permalink raw reply
* [PATCH 0/4] Fix hang of Armada 8040 SoC in orion-mdio
From: josua @ 2019-07-06 15:18 UTC (permalink / raw)
To: netdev; +Cc: Josua Mayer
From: Josua Mayer <josua@solid-run.com>
With a modular kernel as configured by Debian a hang was observed with
the Armada 8040 SoC in the Clearfog GT and Macchiatobin boards.
The 8040 SoC actually requires four clocks to be enabled for the mdio
interface to function. All 4 clocks are already specified in
armada-cp110.dtsi. It has however been missed that the orion-mdio driver
only supports enabling up to three clocks.
This patch-set allows the orion-mdio driver to handle four clocks and
adds a warning when more clocks are specified to prevent this particular
oversight in the future.
Josua Mayer (4):
dt-bindings: allow up to four clocks for orion-mdio
net: mvmdio: allow up to four clocks to be specified for orion-mdio
net: mvmdio: print warning when orion-mdio has too many clocks
net: mvmdio: defer probe of orion-mdio if a clock is not ready
Documentation/devicetree/bindings/net/marvell-orion-mdio.txt | 2 +-
drivers/net/ethernet/marvell/mvmdio.c | 11 ++++++++++-
2 files changed, 11 insertions(+), 2 deletions(-)
--
2.16.4
^ permalink raw reply
* [PATCH 4/4] net: mvmdio: defer probe of orion-mdio if a clock is not ready
From: josua @ 2019-07-06 15:19 UTC (permalink / raw)
To: netdev; +Cc: Josua Mayer, David S. Miller
In-Reply-To: <20190706151900.14355-1-josua@solid-run.com>
From: Josua Mayer <josua@solid-run.com>
Defer probing of the orion-mdio interface when enabling of either of the
clocks defer probing. This avoids locking up the Armada 8k SoC when mdio
is used before all clocks have been enabled.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
drivers/net/ethernet/marvell/mvmdio.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 89a99bf8e87b..1034013426ad 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -321,6 +321,10 @@ static int orion_mdio_probe(struct platform_device *pdev)
for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
+ if (dev->clk[i] == PTR_ERR(-EPROBE_DEFER)) {
+ ret = -EPROBE_DEFER;
+ goto out_clk;
+ }
if (IS_ERR(dev->clk[i]))
break;
clk_prepare_enable(dev->clk[i]);
@@ -366,6 +370,7 @@ static int orion_mdio_probe(struct platform_device *pdev)
if (dev->err_interrupt > 0)
writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
+out_clk:
for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
if (IS_ERR(dev->clk[i]))
break;
--
2.16.4
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: allow up to four clocks for orion-mdio
From: josua @ 2019-07-06 15:18 UTC (permalink / raw)
To: netdev; +Cc: Josua Mayer, stable, David S. Miller, Rob Herring, Mark Rutland
In-Reply-To: <20190706151900.14355-1-josua@solid-run.com>
From: Josua Mayer <josua@solid-run.com>
Armada 8040 needs four clocks to be enabled for MDIO accesses to work.
Update the binding to allow the extra clock to be specified.
Cc: stable@vger.kernel.org
Fixes: 6d6a331f44a1 ("dt-bindings: allow up to three clocks for orion-mdio")
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Documentation/devicetree/bindings/net/marvell-orion-mdio.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
index 42cd81090a2c..3f3cfc1d8d4d 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
@@ -16,7 +16,7 @@ Required properties:
Optional properties:
- interrupts: interrupt line number for the SMI error/done interrupt
-- clocks: phandle for up to three required clocks for the MDIO instance
+- clocks: phandle for up to four required clocks for the MDIO instance
The child nodes of the MDIO driver are the individual PHY devices
connected to this MDIO bus. They must have a "reg" property given the
--
2.16.4
^ permalink raw reply related
* [PATCH 2/4] net: mvmdio: allow up to four clocks to be specified for orion-mdio
From: josua @ 2019-07-06 15:18 UTC (permalink / raw)
To: netdev; +Cc: Josua Mayer, stable, David S. Miller
In-Reply-To: <20190706151900.14355-1-josua@solid-run.com>
From: Josua Mayer <josua@solid-run.com>
Allow up to four clocks to be specified and enabled for the orion-mdio
interface, which are required by the Armada 8k and defined in
armada-cp110.dtsi.
Fixes a hang in probing the mvmdio driver that was encountered on the
Clearfog GT 8K with all drivers built as modules, but also affects other
boards such as the MacchiatoBIN.
Cc: stable@vger.kernel.org
Fixes: 96cb43423822 ("net: mvmdio: allow up to three clocks to be specified for orion-mdio")
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
drivers/net/ethernet/marvell/mvmdio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index c5dac6bd2be4..e17d563e97a6 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -64,7 +64,7 @@
struct orion_mdio_dev {
void __iomem *regs;
- struct clk *clk[3];
+ struct clk *clk[4];
/*
* If we have access to the error interrupt pin (which is
* somewhat misnamed as it not only reflects internal errors
--
2.16.4
^ permalink raw reply related
* Re: [PATCH 1/4] dt-bindings: allow up to four clocks for orion-mdio
From: Andrew Lunn @ 2019-07-06 15:47 UTC (permalink / raw)
To: josua; +Cc: netdev, stable, David S. Miller, Rob Herring, Mark Rutland
In-Reply-To: <20190706151900.14355-2-josua@solid-run.com>
On Sat, Jul 06, 2019 at 05:18:57PM +0200, josua@solid-run.com wrote:
> From: Josua Mayer <josua@solid-run.com>
>
> Armada 8040 needs four clocks to be enabled for MDIO accesses to work.
> Update the binding to allow the extra clock to be specified.
>
> Cc: stable@vger.kernel.org
> Fixes: 6d6a331f44a1 ("dt-bindings: allow up to three clocks for orion-mdio")
> Signed-off-by: Josua Mayer <josua@solid-run.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 2/4] net: mvmdio: allow up to four clocks to be specified for orion-mdio
From: Andrew Lunn @ 2019-07-06 15:47 UTC (permalink / raw)
To: josua; +Cc: netdev, stable, David S. Miller
In-Reply-To: <20190706151900.14355-3-josua@solid-run.com>
On Sat, Jul 06, 2019 at 05:18:58PM +0200, josua@solid-run.com wrote:
> From: Josua Mayer <josua@solid-run.com>
>
> Allow up to four clocks to be specified and enabled for the orion-mdio
> interface, which are required by the Armada 8k and defined in
> armada-cp110.dtsi.
>
> Fixes a hang in probing the mvmdio driver that was encountered on the
> Clearfog GT 8K with all drivers built as modules, but also affects other
> boards such as the MacchiatoBIN.
>
> Cc: stable@vger.kernel.org
> Fixes: 96cb43423822 ("net: mvmdio: allow up to three clocks to be specified for orion-mdio")
> Signed-off-by: Josua Mayer <josua@solid-run.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH 4/4] net: mvmdio: defer probe of orion-mdio if a clock is not ready
From: Andrew Lunn @ 2019-07-06 15:54 UTC (permalink / raw)
To: josua; +Cc: netdev, David S. Miller
In-Reply-To: <20190706151900.14355-5-josua@solid-run.com>
On Sat, Jul 06, 2019 at 05:19:00PM +0200, josua@solid-run.com wrote:
> From: Josua Mayer <josua@solid-run.com>
>
> Defer probing of the orion-mdio interface when enabling of either of the
> clocks defer probing.
Hi Josua
I'm having trouble parsing that sentence.
How about:
Defer probing of the orion-mdio interface when getting a clock returns
EPROBE_DEFER.
Otherwise:
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
This avoids locking up the Armada 8k SoC when mdio
> is used before all clocks have been enabled.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> drivers/net/ethernet/marvell/mvmdio.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
> index 89a99bf8e87b..1034013426ad 100644
> --- a/drivers/net/ethernet/marvell/mvmdio.c
> +++ b/drivers/net/ethernet/marvell/mvmdio.c
> @@ -321,6 +321,10 @@ static int orion_mdio_probe(struct platform_device *pdev)
>
> for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
> dev->clk[i] = of_clk_get(pdev->dev.of_node, i);
> + if (dev->clk[i] == PTR_ERR(-EPROBE_DEFER)) {
> + ret = -EPROBE_DEFER;
> + goto out_clk;
> + }
> if (IS_ERR(dev->clk[i]))
> break;
> clk_prepare_enable(dev->clk[i]);
> @@ -366,6 +370,7 @@ static int orion_mdio_probe(struct platform_device *pdev)
> if (dev->err_interrupt > 0)
> writel(0, dev->regs + MVMDIO_ERR_INT_MASK);
>
> +out_clk:
> for (i = 0; i < ARRAY_SIZE(dev->clk); i++) {
> if (IS_ERR(dev->clk[i]))
> break;
> --
> 2.16.4
>
^ permalink raw reply
* Re: [PATCH v5 bpf-next 1/5] libbpf: add perf buffer API
From: Yonghong Song @ 2019-07-06 15:56 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: Andrii Nakryiko, Kernel Team, bpf@vger.kernel.org,
netdev@vger.kernel.org, Alexei Starovoitov, daniel@iogearbox.net
In-Reply-To: <CAEf4BzZYAN5t+6Kkt+W4ee13PL7dR4FG8P71dFnk_CHWqMmHPQ@mail.gmail.com>
On 7/5/19 10:54 PM, Andrii Nakryiko wrote:
> On Fri, Jul 5, 2019 at 10:42 PM Yonghong Song <yhs@fb.com> wrote:
>>
>>
>>
>> On 7/5/19 9:35 PM, Andrii Nakryiko wrote:
>>> BPF_MAP_TYPE_PERF_EVENT_ARRAY map is often used to send data from BPF program
>>> to user space for additional processing. libbpf already has very low-level API
>>> to read single CPU perf buffer, bpf_perf_event_read_simple(), but it's hard to
>>> use and requires a lot of code to set everything up. This patch adds
>>> perf_buffer abstraction on top of it, abstracting setting up and polling
>>> per-CPU logic into simple and convenient API, similar to what BCC provides.
>>>
>>> perf_buffer__new() sets up per-CPU ring buffers and updates corresponding BPF
>>> map entries. It accepts two user-provided callbacks: one for handling raw
>>> samples and one for get notifications of lost samples due to buffer overflow.
>>>
>>> perf_buffer__new_raw() is similar, but provides more control over how
>>> perf events are set up (by accepting user-provided perf_event_attr), how
>>> they are handled (perf_event_header pointer is passed directly to
>>> user-provided callback), and on which CPUs ring buffers are created
>>> (it's possible to provide a list of CPUs and corresponding map keys to
>>> update). This API allows advanced users fuller control.
>>>
>>> perf_buffer__poll() is used to fetch ring buffer data across all CPUs,
>>> utilizing epoll instance.
>>>
>>> perf_buffer__free() does corresponding clean up and unsets FDs from BPF map.
>>>
>>> All APIs are not thread-safe. User should ensure proper locking/coordination if
>>> used in multi-threaded set up.
>>>
>>> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
>>> ---
>>> tools/lib/bpf/libbpf.c | 366 +++++++++++++++++++++++++++++++++++++++
>>> tools/lib/bpf/libbpf.h | 49 ++++++
>>> tools/lib/bpf/libbpf.map | 4 +
>>> 3 files changed, 419 insertions(+)
>>>
>>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>>> index 2a08eb106221..72149d68b8c1 100644
>>> --- a/tools/lib/bpf/libbpf.c
>>> +++ b/tools/lib/bpf/libbpf.c
>>> @@ -32,7 +32,9 @@
>>> #include <linux/limits.h>
>>> #include <linux/perf_event.h>
>>> #include <linux/ring_buffer.h>
>>> +#include <sys/epoll.h>
>>> #include <sys/ioctl.h>
>>> +#include <sys/mman.h>
>>> #include <sys/stat.h>
>>> #include <sys/types.h>
>>> #include <sys/vfs.h>
>>> @@ -4354,6 +4356,370 @@ bpf_perf_event_read_simple(void *mmap_mem, size_t mmap_size, size_t page_size,
>>> return ret;
>>> }
>>>
>>> +struct perf_buffer;
>>> +
>>> +struct perf_buffer_params {
>>> + struct perf_event_attr *attr;
>>> + /* if event_cb is specified, it takes precendence */
>>> + perf_buffer_event_fn event_cb;
>>> + /* sample_cb and lost_cb are higher-level common-case callbacks */
>>> + perf_buffer_sample_fn sample_cb;
>>> + perf_buffer_lost_fn lost_cb;
>>> + void *ctx;
>>> + int cpu_cnt;
>>> + int *cpus;
>> [...]
>>> +
>>> +int perf_buffer__poll(struct perf_buffer *pb, int timeout_ms)
>>> +{
>>> + int cnt, err;
>>> +
>>> + cnt = epoll_wait(pb->epoll_fd, pb->events, pb->cpu_cnt, timeout_ms);
>>> + for (int i = 0; i < cnt; i++) {
>>
>> Find one compilation error here.
>>
>> libbpf.c: In function ‘perf_buffer__poll’:
>> libbpf.c:4728:2: error: ‘for’ loop initial declarations are only allowed
>> in C99 mode
>> for (int i = 0; i < cnt; i++) {
>> ^
>>
>
> Ah... Fixing, thanks!. How did you compile? make -C tools/lib/bpf
> doesn't show this, should we update libbpf Makefile to catch stuff
> like this?
I did not make any code changes. My compiler is gcc 4.8.5. it is
possible that old compiler less tolerant.
>>> + struct perf_cpu_buf *cpu_buf = pb->events[i].data.ptr;
>>> +
>>> + err = perf_buffer__process_records(pb, cpu_buf);
>>> + if (err) {
>>> + pr_warning("error while processing records: %d\n", err);
>>> + return err;
>>> + }
>>> + }
>>> + return cnt < 0 ? -errno : cnt;
>>> +}
>>> +
>>> struct bpf_prog_info_array_desc {
>>> int array_offset; /* e.g. offset of jited_prog_insns */
>>> int count_offset; /* e.g. offset of jited_prog_len */
>> [...]
^ permalink raw reply
* [PATCH 3/4] net: mvmdio: print warning when orion-mdio has too many clocks
From: josua @ 2019-07-06 15:18 UTC (permalink / raw)
To: netdev; +Cc: Josua Mayer, David S. Miller
In-Reply-To: <20190706151900.14355-1-josua@solid-run.com>
From: Josua Mayer <josua@solid-run.com>
Print a warning when device tree specifies more than the maximum of four
clocks supported by orion-mdio. Because reading from mdio can lock up
the Armada 8k when a required clock is not initialized, it is important
to notify the user when a specified clock is ignored.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
drivers/net/ethernet/marvell/mvmdio.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index e17d563e97a6..89a99bf8e87b 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -326,6 +326,10 @@ static int orion_mdio_probe(struct platform_device *pdev)
clk_prepare_enable(dev->clk[i]);
}
+ if (!IS_ERR(of_clk_get(pdev->dev.of_node, i)))
+ dev_warn(dev, "unsupported number of clocks, limiting to the first "
+ __stringify(ARRAY_SIZE(dev->clk)) "\n");
+
dev->err_interrupt = platform_get_irq(pdev, 0);
if (dev->err_interrupt > 0 &&
resource_size(r) < MVMDIO_ERR_INT_MASK + 4) {
--
2.16.4
^ permalink raw reply related
* RE: [net-next 1/3] ice: Initialize and register platform device to provide RDMA
From: Saleem, Shiraz @ 2019-07-06 16:03 UTC (permalink / raw)
To: Greg KH
Cc: Jason Gunthorpe, Kirsher, Jeffrey T, davem@davemloft.net,
dledford@redhat.com, Nguyen, Anthony L, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, nhorman@redhat.com,
sassmann@redhat.com, poswald@suse.com, Ismail, Mustafa,
Ertman, David M, Bowers, AndrewX
In-Reply-To: <20190706082523.GA8727@kroah.com>
> Subject: Re: [net-next 1/3] ice: Initialize and register platform device to provide
> RDMA
>
> On Fri, Jul 05, 2019 at 04:33:07PM +0000, Saleem, Shiraz wrote:
> > > Subject: Re: [net-next 1/3] ice: Initialize and register platform
> > > device to provide RDMA
> > >
> > > On Thu, Jul 04, 2019 at 12:48:29PM +0000, Jason Gunthorpe wrote:
> > > > On Thu, Jul 04, 2019 at 02:42:47PM +0200, Greg KH wrote:
> > > > > On Thu, Jul 04, 2019 at 12:37:33PM +0000, Jason Gunthorpe wrote:
> > > > > > On Thu, Jul 04, 2019 at 02:29:50PM +0200, Greg KH wrote:
> > > > > > > On Thu, Jul 04, 2019 at 12:16:41PM +0000, Jason Gunthorpe wrote:
> > > > > > > > On Wed, Jul 03, 2019 at 07:12:50PM -0700, Jeff Kirsher wrote:
> > > > > > > > > From: Tony Nguyen <anthony.l.nguyen@intel.com>
> > > > > > > > >
> > > > > > > > > The RDMA block does not advertise on the PCI bus or any other
> bus.
> > > > > > > > > Thus the ice driver needs to provide access to the RDMA
> > > > > > > > > hardware block via a virtual bus; utilize the platform
> > > > > > > > > bus to provide this
> > > access.
> > > > > > > > >
> > > > > > > > > This patch initializes the driver to support RDMA as
> > > > > > > > > well as creates and registers a platform device for the
> > > > > > > > > RDMA driver to register to. At this point the driver is
> > > > > > > > > fully initialized to register a platform driver,
> > > > > > > > > however, can not yet register as the ops have not been
> implemented.
> > > > > > > >
> > > > > > > > I think you need Greg's ack on all this driver stuff -
> > > > > > > > particularly that a platform_device is OK.
> > > > > > >
> > > > > > > A platform_device is almost NEVER ok.
> > > > > > >
> > > > > > > Don't abuse it, make a real device on a real bus. If you
> > > > > > > don't have a real bus and just need to create a device to
> > > > > > > hang other things off of, then use the virtual one, that's what it is there
> for.
> > > > > >
> > > > > > Ideally I'd like to see all the RDMA drivers that connect to
> > > > > > ethernet drivers use some similar scheme.
> > > > >
> > > > > Why? They should be attached to a "real" device, why make any up?
> > > >
> > > > ? A "real" device, like struct pci_device, can only bind to one
> > > > driver. How can we bind it concurrently to net, rdma, scsi, etc?
> > >
> > > MFD was designed for this very problem.
> > >
> > > > > > This is for a PCI device that plugs into multiple subsystems
> > > > > > in the kernel, ie it has net driver functionality, rdma
> > > > > > functionality, some even have SCSI functionality
> > > > >
> > > > > Sounds like a MFD device, why aren't you using that
> > > > > functionality instead?
> > > >
> > > > This was also my advice, but in another email Jeff says:
> > > >
> > > > MFD architecture was also considered, and we selected the simpler
> > > > platform model. Supporting a MFD architecture would require an
> > > > additional MFD core driver, individual platform netdev, RDMA function
> > > > drivers, and stripping a large portion of the netdev drivers into
> > > > MFD core. The sub-devices registered by MFD core for function
> > > > drivers are indeed platform devices.
> > >
> > > So, "mfd is too hard, let's abuse a platform device" is ok?
> > >
> > > People have been wanting to do MFD drivers for PCI devices for a
> > > long time, it's about time someone actually did the work for it, I
> > > bet it will not be all that complex if tiny embedded drivers can do
> > > it :)
> > >
> > Hi Greg - Thanks for your feedback!
> >
> > We currently have 2 PCI function netdev drivers in the kernel (i40e &
> > ice) that support devices (x722 & e810) which are RDMA capable. Our
> > objective is to add a single unified RDMA driver (as this a subsystem
> > specific requirement) which needs to access HW resources from the
> > netdev PF drivers. Attaching platform devices from the netdev drivers
> > to the platform bus and having a single RDMA platform driver bind to
> > them and access these resources seemed like a simple approach to realize our
> objective. But seems like attaching platform devices is wrong. I would like to
> understand why.
>
> Because that is NOT what a platform device is for.
>
> It was originally created for those types of devices that live on the "platform" bus,
> i.e. things that are hard-wired and you just "know" are in your system because they
> are located at specific locations. We used to generate them from board files, and
> then when we got DT, we create them from the resources that DT says where the
> locations of the devices are.
>
> They are NOT to be abused and used whenever someone wants to put them
> somewhere in the "middle" of the device tree because they feel like they are easier
> to use instead of creating a real bus and drivers.
>
> Yes, they do get abused, and I need to sweep the tree again and fix up all of the
> places where this has crept back in. But now that I know you are thinking of doing
> this, I'll keep saying to NOT do it for your use case either :)
Thanks Greg for the explanation.
And yes, we went by some example usages in the tree.
>
> > Are platform sub devices only to be added from an MFD core driver? I
> > am also wondering if MFD arch. would allow for realizing a single
> > RDMA driver and whether we need an MFD core driver for each device,
> > x722 & e810 or whether it can be a single driver.
>
> I do not know the details of how MFD works, please ask those developers for
> specifics. If MFD doesn't work, then create a tiny virtual bus and make sub-
> devices out of that. If you need a "generic" way to do this for PCI devices, then
> please create that as you are not the only one that keeps wanting this, as for some
> reason PCI hardware vendors don't like dividing up their devices in ways that
> would have made it much simpler to create individual devices (probably saves
> some gates and firmware complexity on the device).
>
Thank you for laying out options. We will review internally and get back.
Shiraz
^ permalink raw reply
* Re: [PATCH 3/4] net: mvmdio: print warning when orion-mdio has too many clocks
From: Andrew Lunn @ 2019-07-06 16:09 UTC (permalink / raw)
To: josua; +Cc: netdev, David S. Miller
In-Reply-To: <20190706151900.14355-4-josua@solid-run.com>
On Sat, Jul 06, 2019 at 05:18:59PM +0200, josua@solid-run.com wrote:
> From: Josua Mayer <josua@solid-run.com>
>
> Print a warning when device tree specifies more than the maximum of four
> clocks supported by orion-mdio. Because reading from mdio can lock up
> the Armada 8k when a required clock is not initialized, it is important
> to notify the user when a specified clock is ignored.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> drivers/net/ethernet/marvell/mvmdio.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
> index e17d563e97a6..89a99bf8e87b 100644
> --- a/drivers/net/ethernet/marvell/mvmdio.c
> +++ b/drivers/net/ethernet/marvell/mvmdio.c
> @@ -326,6 +326,10 @@ static int orion_mdio_probe(struct platform_device *pdev)
> clk_prepare_enable(dev->clk[i]);
> }
>
> + if (!IS_ERR(of_clk_get(pdev->dev.of_node, i)))
> + dev_warn(dev, "unsupported number of clocks, limiting to the first "
> + __stringify(ARRAY_SIZE(dev->clk)) "\n");
> +
Hi Josua
Humm. Say getting clock 0 returned -EINVAL, or some other error code.
We break out of the loop, since such errors are being ignored. We then
hit this new code. Getting clock 1 works, and then we incorrectly
print this message.
Rather than getting the i'th clock, get ARRAY_SIZE(dev->clk)'th clock.
Andrew
^ permalink raw reply
* RE: [rdma 14/16] RDMA/irdma: Add ABI definitions
From: Saleem, Shiraz @ 2019-07-06 16:15 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Leon Romanovsky, Kirsher, Jeffrey T, dledford@redhat.com,
davem@davemloft.net, Ismail, Mustafa, linux-rdma@vger.kernel.org,
netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
poswald@suse.com, Ertman, David M
In-Reply-To: <20190705171650.GI31525@mellanox.com>
> Subject: Re: [rdma 14/16] RDMA/irdma: Add ABI definitions
>
> On Fri, Jul 05, 2019 at 04:42:19PM +0000, Saleem, Shiraz wrote:
> > > Subject: Re: [rdma 14/16] RDMA/irdma: Add ABI definitions
> > >
> > > On Thu, Jul 04, 2019 at 10:40:21AM +0300, Leon Romanovsky wrote:
> > > > On Wed, Jul 03, 2019 at 07:12:57PM -0700, Jeff Kirsher wrote:
> > > > > From: Mustafa Ismail <mustafa.ismail@intel.com>
> > > > >
> > > > > Add ABI definitions for irdma.
> > > > >
> > > > > Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com>
> > > > > Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
> > > > > include/uapi/rdma/irdma-abi.h | 130
> > > > > ++++++++++++++++++++++++++++++++++
> > > > > 1 file changed, 130 insertions(+) create mode 100644
> > > > > include/uapi/rdma/irdma-abi.h
> > > > >
> > > > > diff --git a/include/uapi/rdma/irdma-abi.h
> > > > > b/include/uapi/rdma/irdma-abi.h new file mode 100644 index
> > > > > 000000000000..bdfbda4c829e
> > > > > +++ b/include/uapi/rdma/irdma-abi.h
> > > > > @@ -0,0 +1,130 @@
> > > > > +/* SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */
> > > > > +/* Copyright (c) 2006 - 2019 Intel Corporation. All rights reserved.
> > > > > + * Copyright (c) 2005 Topspin Communications. All rights reserved.
> > > > > + * Copyright (c) 2005 Cisco Systems. All rights reserved.
> > > > > + * Copyright (c) 2005 Open Grid Computing, Inc. All rights reserved.
> > > > > + */
> > > > > +
> > > > > +#ifndef IRDMA_ABI_H
> > > > > +#define IRDMA_ABI_H
> > > > > +
> > > > > +#include <linux/types.h>
> > > > > +
> > > > > +/* irdma must support legacy GEN_1 i40iw kernel
> > > > > + * and user-space whose last ABI ver is 5 */ #define
> > > > > +IRDMA_ABI_VER
> > > > > +6
> > > >
> > > > Can you please elaborate about it more?
> > > > There is no irdma code in RDMA yet, so it makes me wonder why new
> > > > define shouldn't start from 1.
> > >
> > > It is because they are ABI compatible with the current user space,
> > > which raises the question why we even have this confusing header file..
> >
> > It is because we need to support current providers/i40iw user-space.
> > Our user-space patch series will introduce a new provider (irdma)
> > whose ABI ver. is also 6 (capable of supporting X722 and which will
> > work with i40iw driver on older kernels) and removes providers/i40iw from rdma-
> core.
>
> Why on earth would we do that?
>
A unified library providers/irdma to go in hand with the driver irdma and uses the ABI header.
It can support the new network device e810 and existing x722 iWARP device. It obsoletes
providers/i40iw and extends its ABI. So why keep providers/i40iw around in rdma-core?
Shiraz
^ permalink raw reply
* Re: Kernel BUG: epoll_wait() (and epoll_pwait) stall for 206 ms per call on sockets with a small-ish snd/rcv buffer.
From: Carlo Wood @ 2019-07-06 16:16 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <20190706034508.43aabff0@hikaru>
I improved the test case a bit:
https://github.com/CarloWood/ai-evio-testsuite/blob/2a9ae49e3ae39eea7cb1d105883254370f53831b/src/epoll_bug.c
If the bug doesn't show, please increase burst_size and/or decrease
sndbuf_size and rcvbuf_size.
The output that I get with VERBOSE defined is for example:
[...snip...]
wrote 34784 bytes to 6 (total written now 9665792), now in pipe line: 34784
Read 34784 bytes from fd 5 (total read now 9665792), left in pipe line: 0
wrote 34784 bytes to 6 (total written now 9700576), now in pipe line: 34784
Read 34784 bytes from fd 5 (total read now 9700576), left in pipe line: 0
wrote 34784 bytes to 6 (total written now 9735360), now in pipe line: 34784
Read 34784 bytes from fd 5 (total read now 9735360), left in pipe line: 0
wrote 34784 bytes to 6 (total written now 9770144), now in pipe line: 34784
Read 34784 bytes from fd 5 (total read now 9770144), left in pipe line: 0
wrote 34784 bytes to 6 (total written now 9804928), now in pipe line: 34784
Read 34784 bytes from fd 5 (total read now 9804928), left in pipe line: 0
wrote 34784 bytes to 6 (total written now 9839712), now in pipe line: 34784
Read 34784 bytes from fd 5 (total read now 9839712), left in pipe line: 0
wrote 34784 bytes to 6 (total written now 9874496), now in pipe line: 34784
Read 34784 bytes from fd 5 (total read now 9874496), left in pipe line: 0
wrote 34784 bytes to 6 (total written now 9909280), now in pipe line: 34784
Read 34784 bytes from fd 5 (total read now 9909280), left in pipe line: 0
wrote 34784 bytes to 6 (total written now 9944064), now in pipe line: 34784
Read 34784 bytes from fd 5 (total read now 9944064), left in pipe line: 0
wrote 34784 bytes to 6 (total written now 9978848), now in pipe line: 34784
Read 34784 bytes from fd 5 (total read now 9978848), left in pipe line: 0
wrote 21152 bytes to 6 (total written now 10000000), now in pipe line: 21152
Read 21152 bytes from fd 5 (total read now 10000000), left in pipe line: 0
epoll_wait() stalled 193 milliseconds!
Read 21888 bytes from fd 6 (total read now 70912), left in pipe line: 21888
epoll_wait() stalled 255 milliseconds!
Read 21888 bytes from fd 6 (total read now 92800), left in pipe line: 0
write(5, buf, 9907200) = 43776 (total written now 136576), now in pipe line: 43776
epoll_wait() stalled 211 milliseconds!
Read 21888 bytes from fd 6 (total read now 114688), left in pipe line: 21888
epoll_wait() stalled 207 milliseconds!
write(5, buf, 9863424) = 38272 (total written now 174848), now in pipe line: 60160
Read 16384 bytes from fd 6 (total read now 131072), left in pipe line: 43776
epoll_wait() stalled 207 milliseconds!
Read 21888 bytes from fd 6 (total read now 152960), left in pipe line: 21888
epoll_wait() stalled 207 milliseconds!
Read 21888 bytes from fd 6 (total read now 174848), left in pipe line: 0
write(5, buf, 9825152) = 43776 (total written now 218624), now in pipe line: 43776
epoll_wait() stalled 207 milliseconds!
Read 21888 bytes from fd 6 (total read now 196736), left in pipe line: 21888
epoll_wait() stalled 211 milliseconds!
Read 21888 bytes from fd 6 (total read now 218624), left in pipe line: 0
write(5, buf, 9781376) = 43776 (total written now 262400), now in pipe line: 43776
epoll_wait() stalled 207 milliseconds!
Read 21888 bytes from fd 6 (total read now 240512), left in pipe line: 21888
epoll_wait() stalled 207 milliseconds!
Read 21888 bytes from fd 6 (total read now 262400), left in pipe line: 0
write(5, buf, 9737600) = 43776 (total written now 306176), now in pipe line: 43776
epoll_wait() stalled 207 milliseconds!
Read 21888 bytes from fd 6 (total read now 284288), left in pipe line: 21888
epoll_wait() stalled 207 milliseconds!
Read 21888 bytes from fd 6 (total read now 306176), left in pipe line: 0
write(5, buf, 9693824) = 43776 (total written now 349952), now in pipe line: 43776
epoll_wait() stalled 207 milliseconds!
Read 21888 bytes from fd 6 (total read now 328064), left in pipe line: 21888
epoll_wait() stalled 207 milliseconds!
write(5, buf, 9650048) = 38272 (total written now 388224), now in pipe line: 60160
Read 16384 bytes from fd 6 (total read now 344448), left in pipe line: 43776
epoll_wait() stalled 207 milliseconds!
... etc. etc.
It seems that the problem always occur right after stopping to write data in one
direction, and then happens for the way back.
In the case above the burst_size is set to 10000000 bytes, and it writes
that amount and reads it on the other side successfully.
What I think is going on however is that the data on the way back is stalling,
during which the "forward" burst finishes (without the epoll_wait stalling it
is VERY fast). Above you see:
Read 21152 bytes from fd 5 (total read now 10000000), left in pipe line: 0
epoll_wait() stalled 193 milliseconds!
But since we know that the stall always seems to be 207ms, I'm pretty sure
that actually it stalled 14 ms before that, and needed 14 ms to finish the
complete burst in one direction.
--
Carlo Wood <carlo@alinoe.com>
^ permalink raw reply
* Re: [PATCH 3/4] net: mvmdio: print warning when orion-mdio has too many clocks
From: Josua Mayer @ 2019-07-06 16:21 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, David S. Miller
In-Reply-To: <20190706160925.GI4428@lunn.ch>
Hi Andrew,
Am 06.07.19 um 18:09 schrieb Andrew Lunn:
> On Sat, Jul 06, 2019 at 05:18:59PM +0200, josua@solid-run.com wrote:
>> From: Josua Mayer <josua@solid-run.com>
>>
>> Print a warning when device tree specifies more than the maximum of four
>> clocks supported by orion-mdio. Because reading from mdio can lock up
>> the Armada 8k when a required clock is not initialized, it is important
>> to notify the user when a specified clock is ignored.
>>
>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>> ---
>> drivers/net/ethernet/marvell/mvmdio.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
>> index e17d563e97a6..89a99bf8e87b 100644
>> --- a/drivers/net/ethernet/marvell/mvmdio.c
>> +++ b/drivers/net/ethernet/marvell/mvmdio.c
>> @@ -326,6 +326,10 @@ static int orion_mdio_probe(struct platform_device *pdev)
>> clk_prepare_enable(dev->clk[i]);
>> }
>>
>> + if (!IS_ERR(of_clk_get(pdev->dev.of_node, i)))
>> + dev_warn(dev, "unsupported number of clocks, limiting to the first "
>> + __stringify(ARRAY_SIZE(dev->clk)) "\n");
>> +
> Hi Josua
>
> Humm. Say getting clock 0 returned -EINVAL, or some other error code.
> We break out of the loop, since such errors are being ignored. We then
> hit this new code. Getting clock 1 works, and then we incorrectly
> print this message.
Good point about breaking out of the loop! I did indeed not take the
break condition of the loop into account.
I can not exactly follow your example though. The first failure of
of_clk_get will trigger break and exit the loop,
and then we would indeed print the wrong message ... .
>
> Rather than getting the i'th clock, get ARRAY_SIZE(dev->clk)'th clock.
I will gladly make the change in a v2.
> Andrew
-
Josua
^ permalink raw reply
* [PATCH 1/2] proc: revalidate directories created with proc_net_mkdir()
From: Alexey Dobriyan @ 2019-07-06 16:52 UTC (permalink / raw)
To: davem; +Cc: netdev, Per.Hallsmark
/proc/net directories may contain content which depends on net namespace.
Such dentries should be revalidated after setns(CLONE_NEWNET).
See
commit 1fde6f21d90f8ba5da3cb9c54ca991ed72696c43
proc: fix /proc/net/* after setns(2)
The patch is all about "pde_force_lookup()" line.
[redid original patch --adobriyan]
Reported-by: "Hallsmark, Per" <Per.Hallsmark@windriver.com>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
fs/proc/generic.c | 25 ++++++++++++++++++-------
fs/proc/internal.h | 3 +++
fs/proc/proc_net.c | 17 +++++++++++++++++
include/linux/proc_fs.h | 16 ++++++++--------
4 files changed, 46 insertions(+), 15 deletions(-)
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -459,26 +459,37 @@ struct proc_dir_entry *proc_symlink(const char *name,
}
EXPORT_SYMBOL(proc_symlink);
-struct proc_dir_entry *proc_mkdir_data(const char *name, umode_t mode,
- struct proc_dir_entry *parent, void *data)
+struct proc_dir_entry *_proc_mkdir(const char *name, umode_t mode,
+ struct proc_dir_entry **parent, void *data)
{
struct proc_dir_entry *ent;
if (mode == 0)
mode = S_IRUGO | S_IXUGO;
- ent = __proc_create(&parent, name, S_IFDIR | mode, 2);
+ ent = __proc_create(parent, name, S_IFDIR | mode, 2);
if (ent) {
ent->data = data;
ent->proc_fops = &proc_dir_operations;
ent->proc_iops = &proc_dir_inode_operations;
- parent->nlink++;
- ent = proc_register(parent, ent);
- if (!ent)
- parent->nlink--;
}
return ent;
}
+
+struct proc_dir_entry *proc_mkdir_data(const char *name, umode_t mode,
+ struct proc_dir_entry *parent, void *data)
+{
+ struct proc_dir_entry *pde;
+
+ pde = _proc_mkdir(name, mode, &parent, data);
+ if (!pde)
+ return NULL;
+ parent->nlink++;
+ pde = proc_register(parent, pde);
+ if (!pde)
+ parent->nlink--;
+ return pde;
+}
EXPORT_SYMBOL_GPL(proc_mkdir_data);
struct proc_dir_entry *proc_mkdir_mode(const char *name, umode_t mode,
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -299,3 +299,6 @@ extern unsigned long task_statm(struct mm_struct *,
unsigned long *, unsigned long *,
unsigned long *, unsigned long *);
extern void task_mem(struct seq_file *, struct mm_struct *);
+
+struct proc_dir_entry *_proc_mkdir(const char *name, umode_t mode,
+ struct proc_dir_entry **parent, void *data);
--- a/fs/proc/proc_net.c
+++ b/fs/proc/proc_net.c
@@ -251,6 +251,23 @@ struct proc_dir_entry *proc_create_net_single_write(const char *name, umode_t mo
}
EXPORT_SYMBOL_GPL(proc_create_net_single_write);
+struct proc_dir_entry *proc_net_mkdir(struct net *net, const char *name,
+ struct proc_dir_entry *parent)
+{
+ struct proc_dir_entry *pde;
+
+ pde = _proc_mkdir(name, 0, &parent, net);
+ if (!pde)
+ return NULL;
+ pde_force_lookup(pde);
+ parent->nlink++;
+ pde = proc_register(parent, pde);
+ if (!pde)
+ parent->nlink++;
+ return pde;
+}
+EXPORT_SYMBOL_GPL(proc_net_mkdir);
+
static struct net *get_proc_task_net(struct inode *dir)
{
struct task_struct *task;
--- a/include/linux/proc_fs.h
+++ b/include/linux/proc_fs.h
@@ -8,6 +8,7 @@
#include <linux/types.h>
#include <linux/fs.h>
+struct net;
struct proc_dir_entry;
struct seq_file;
struct seq_operations;
@@ -73,6 +74,8 @@ struct proc_dir_entry *proc_create_net_single_write(const char *name, umode_t mo
int (*show)(struct seq_file *, void *),
proc_write_t write,
void *data);
+struct proc_dir_entry *proc_net_mkdir(struct net *net, const char *name, struct proc_dir_entry *parent);
+
extern struct pid *tgid_pidfd_to_pid(const struct file *file);
#else /* CONFIG_PROC_FS */
@@ -115,6 +118,11 @@ static inline int remove_proc_subtree(const char *name, struct proc_dir_entry *p
#define proc_create_net(name, mode, parent, state_size, ops) ({NULL;})
#define proc_create_net_single(name, mode, parent, show, data) ({NULL;})
+static inline struct proc_dir_entry *proc_net_mkdir(struct net *net, const char *name, struct proc_dir_entry *parent)
+{
+ return NULL;
+}
+
static inline struct pid *tgid_pidfd_to_pid(const struct file *file)
{
return ERR_PTR(-EBADF);
@@ -122,14 +130,6 @@ static inline struct pid *tgid_pidfd_to_pid(const struct file *file)
#endif /* CONFIG_PROC_FS */
-struct net;
-
-static inline struct proc_dir_entry *proc_net_mkdir(
- struct net *net, const char *name, struct proc_dir_entry *parent)
-{
- return proc_mkdir_data(name, 0, parent, net);
-}
-
struct ns_common;
int open_related_ns(struct ns_common *ns,
struct ns_common *(*get_ns)(struct ns_common *ns));
^ permalink raw reply
* [PATCH 2/2] net: apply proc_net_mkdir() harder
From: Alexey Dobriyan @ 2019-07-06 16:55 UTC (permalink / raw)
To: davem
Cc: netdev, netfilter-devel, linux-nfs, j.vosburgh, vfalico, andy,
pablo, kadlec, fw, bfields, chuck.lever
From: "Hallsmark, Per" <Per.Hallsmark@windriver.com>
proc_net_mkdir() should be used to create stuff under /proc/net,
so that dentry revalidation kicks in.
See
commit 1fde6f21d90f8ba5da3cb9c54ca991ed72696c43
proc: fix /proc/net/* after setns(2)
[added more chunks --adobriyan]
Signed-off-by: "Hallsmark, Per" <Per.Hallsmark@windriver.com>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/net/bonding/bond_procfs.c | 2 +-
net/core/pktgen.c | 2 +-
net/ipv4/netfilter/ipt_CLUSTERIP.c | 2 +-
net/ipv6/proc.c | 2 +-
net/netfilter/xt_hashlimit.c | 4 ++--
net/netfilter/xt_recent.c | 2 +-
net/sunrpc/stats.c | 2 +-
7 files changed, 8 insertions(+), 8 deletions(-)
--- a/drivers/net/bonding/bond_procfs.c
+++ b/drivers/net/bonding/bond_procfs.c
@@ -293,7 +293,7 @@ void bond_remove_proc_entry(struct bonding *bond)
void __net_init bond_create_proc_dir(struct bond_net *bn)
{
if (!bn->proc_dir) {
- bn->proc_dir = proc_mkdir(DRV_NAME, bn->net->proc_net);
+ bn->proc_dir = proc_net_mkdir(bn->net, DRV_NAME, bn->net->proc_net);
if (!bn->proc_dir)
pr_warn("Warning: Cannot create /proc/net/%s\n",
DRV_NAME);
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3791,7 +3791,7 @@ static int __net_init pg_net_init(struct net *net)
pn->net = net;
INIT_LIST_HEAD(&pn->pktgen_threads);
pn->pktgen_exiting = false;
- pn->proc_dir = proc_mkdir(PG_PROC_DIR, pn->net->proc_net);
+ pn->proc_dir = proc_net_mkdir(pn->net, PG_PROC_DIR, pn->net->proc_net);
if (!pn->proc_dir) {
pr_warn("cannot create /proc/net/%s\n", PG_PROC_DIR);
return -ENODEV;
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -828,7 +828,7 @@ static int clusterip_net_init(struct net *net)
return ret;
#ifdef CONFIG_PROC_FS
- cn->procdir = proc_mkdir("ipt_CLUSTERIP", net->proc_net);
+ cn->procdir = proc_net_mkdir(net, "ipt_CLUSTERIP", net->proc_net);
if (!cn->procdir) {
nf_unregister_net_hook(net, &cip_arp_ops);
pr_err("Unable to proc dir entry\n");
--- a/net/ipv6/proc.c
+++ b/net/ipv6/proc.c
@@ -282,7 +282,7 @@ static int __net_init ipv6_proc_init_net(struct net *net)
snmp6_seq_show, NULL))
goto proc_snmp6_fail;
- net->mib.proc_net_devsnmp6 = proc_mkdir("dev_snmp6", net->proc_net);
+ net->mib.proc_net_devsnmp6 = proc_net_mkdir(net, "dev_snmp6", net->proc_net);
if (!net->mib.proc_net_devsnmp6)
goto proc_dev_snmp6_fail;
return 0;
--- a/net/netfilter/xt_hashlimit.c
+++ b/net/netfilter/xt_hashlimit.c
@@ -1237,11 +1237,11 @@ static int __net_init hashlimit_proc_net_init(struct net *net)
{
struct hashlimit_net *hashlimit_net = hashlimit_pernet(net);
- hashlimit_net->ipt_hashlimit = proc_mkdir("ipt_hashlimit", net->proc_net);
+ hashlimit_net->ipt_hashlimit = proc_net_mkdir(net, "ipt_hashlimit", net->proc_net);
if (!hashlimit_net->ipt_hashlimit)
return -ENOMEM;
#if IS_ENABLED(CONFIG_IP6_NF_IPTABLES)
- hashlimit_net->ip6t_hashlimit = proc_mkdir("ip6t_hashlimit", net->proc_net);
+ hashlimit_net->ip6t_hashlimit = proc_net_mkdir(net, "ip6t_hashlimit", net->proc_net);
if (!hashlimit_net->ip6t_hashlimit) {
remove_proc_entry("ipt_hashlimit", net->proc_net);
return -ENOMEM;
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -629,7 +629,7 @@ static int __net_init recent_proc_net_init(struct net *net)
{
struct recent_net *recent_net = recent_pernet(net);
- recent_net->xt_recent = proc_mkdir("xt_recent", net->proc_net);
+ recent_net->xt_recent = proc_net_mkdir(net, "xt_recent", net->proc_net);
if (!recent_net->xt_recent)
return -ENOMEM;
return 0;
--- a/net/sunrpc/stats.c
+++ b/net/sunrpc/stats.c
@@ -323,7 +323,7 @@ int rpc_proc_init(struct net *net)
dprintk("RPC: registering /proc/net/rpc\n");
sn = net_generic(net, sunrpc_net_id);
- sn->proc_net_rpc = proc_mkdir("rpc", net->proc_net);
+ sn->proc_net_rpc = proc_net_mkdir(net, "rpc", net->proc_net);
if (sn->proc_net_rpc == NULL)
return -ENOMEM;
^ permalink raw reply
* Re: [PATCH v6 bpf-next 3/5] selftests/bpf: test perf buffer API
From: Yonghong Song @ 2019-07-06 17:18 UTC (permalink / raw)
To: Andrii Nakryiko, andrii.nakryiko@gmail.com, bpf@vger.kernel.org,
netdev@vger.kernel.org, Alexei Starovoitov, daniel@iogearbox.net,
Kernel Team
In-Reply-To: <20190706060220.1801632-4-andriin@fb.com>
On 7/5/19 11:02 PM, Andrii Nakryiko wrote:
> Add test verifying perf buffer API functionality.
>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> Acked-by: Song Liu <songliubraving@fb.com>
> ---
> .../selftests/bpf/prog_tests/perf_buffer.c | 94 +++++++++++++++++++
> .../selftests/bpf/progs/test_perf_buffer.c | 25 +++++
> 2 files changed, 119 insertions(+)
> create mode 100644 tools/testing/selftests/bpf/prog_tests/perf_buffer.c
> create mode 100644 tools/testing/selftests/bpf/progs/test_perf_buffer.c
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/perf_buffer.c b/tools/testing/selftests/bpf/prog_tests/perf_buffer.c
> new file mode 100644
> index 000000000000..64556ab0d1a9
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/perf_buffer.c
> @@ -0,0 +1,94 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#define _GNU_SOURCE
> +#include <pthread.h>
> +#include <sched.h>
> +#include <sys/socket.h>
> +#include <test_progs.h>
> +
> +static void on_sample(void *ctx, int cpu, void *data, __u32 size)
> +{
> + int cpu_data = *(int *)data, duration = 0;
> + cpu_set_t *cpu_seen = ctx;
> +
> + if (cpu_data != cpu)
> + CHECK(cpu_data != cpu, "check_cpu_data",
> + "cpu_data %d != cpu %d\n", cpu_data, cpu);
> +
> + CPU_SET(cpu, cpu_seen);
> +}
> +
> +void test_perf_buffer(void)
> +{
> + int err, prog_fd, nr_cpus, i, duration = 0;
> + const char *prog_name = "kprobe/sys_nanosleep";
> + const char *file = "./test_perf_buffer.o";
> + struct perf_buffer_opts pb_opts = {};
> + struct bpf_map *perf_buf_map;
> + cpu_set_t cpu_set, cpu_seen;
> + struct bpf_program *prog;
> + struct bpf_object *obj;
> + struct perf_buffer *pb;
> + struct bpf_link *link;
> +
> + nr_cpus = libbpf_num_possible_cpus();
> + if (CHECK(nr_cpus < 0, "nr_cpus", "err %d\n", nr_cpus))
> + return;
> +
> + /* load program */
> + err = bpf_prog_load(file, BPF_PROG_TYPE_KPROBE, &obj, &prog_fd);
> + if (CHECK(err, "obj_load", "err %d errno %d\n", err, errno))
> + return;
> +
> + prog = bpf_object__find_program_by_title(obj, prog_name);
> + if (CHECK(!prog, "find_probe", "prog '%s' not found\n", prog_name))
> + goto out_close;
> +
> + /* load map */
> + perf_buf_map = bpf_object__find_map_by_name(obj, "perf_buf_map");
> + if (CHECK(!perf_buf_map, "find_perf_buf_map", "not found\n"))
> + goto out_close;
> +
> + /* attach kprobe */
> + link = bpf_program__attach_kprobe(prog, false /* retprobe */,
> + "sys_nanosleep");
The attach function "sys_nanosleep" won't work. You can have something
similar to attach_probe.c.
#ifdef __x86_64__
#define SYS_KPROBE_NAME "__x64_sys_nanosleep"
#else
#define SYS_KPROBE_NAME "sys_nanosleep"
#endif
> + if (CHECK(IS_ERR(link), "attach_kprobe", "err %ld\n", PTR_ERR(link)))
> + goto out_close;
> +
> + /* set up perf buffer */
> + pb_opts.sample_cb = on_sample;
> + pb_opts.ctx = &cpu_seen;
> + pb = perf_buffer__new(bpf_map__fd(perf_buf_map), 1, &pb_opts);
> + if (CHECK(IS_ERR(pb), "perf_buf__new", "err %ld\n", PTR_ERR(pb)))
> + goto out_detach;
> +
> + /* trigger kprobe on every CPU */
> + CPU_ZERO(&cpu_seen);
> + for (i = 0; i < nr_cpus; i++) {
> + CPU_ZERO(&cpu_set);
> + CPU_SET(i, &cpu_set);
> +
> + err = pthread_setaffinity_np(pthread_self(), sizeof(cpu_set),
> + &cpu_set);
> + if (err && CHECK(err, "set_affinity", "cpu #%d, err %d\n",
> + i, err))
> + goto out_detach;
> +
> + usleep(1);
> + }
> +
> + /* read perf buffer */
> + err = perf_buffer__poll(pb, 100);
> + if (CHECK(err < 0, "perf_buffer__poll", "err %d\n", err))
> + goto out_free_pb;
> +
> + if (CHECK(CPU_COUNT(&cpu_seen) != nr_cpus, "seen_cpu_cnt",
> + "expect %d, seen %d\n", nr_cpus, CPU_COUNT(&cpu_seen)))
> + goto out_free_pb;
> +
> +out_free_pb:
> + perf_buffer__free(pb);
> +out_detach:
> + bpf_link__destroy(link);
> +out_close:
> + bpf_object__close(obj);
> +}
> diff --git a/tools/testing/selftests/bpf/progs/test_perf_buffer.c b/tools/testing/selftests/bpf/progs/test_perf_buffer.c
> new file mode 100644
> index 000000000000..876c27deb65a
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/test_perf_buffer.c
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2019 Facebook
> +
> +#include <linux/ptrace.h>
> +#include <linux/bpf.h>
> +#include "bpf_helpers.h"
> +
> +struct {
> + __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY);
> + __uint(key_size, sizeof(int));
> + __uint(value_size, sizeof(int));
> +} perf_buf_map SEC(".maps");
> +
> +SEC("kprobe/sys_nanosleep")
> +int handle_sys_nanosleep_entry(struct pt_regs *ctx)
> +{
> + int cpu = bpf_get_smp_processor_id();
> +
> + bpf_perf_event_output(ctx, &perf_buf_map, BPF_F_CURRENT_CPU,
> + &cpu, sizeof(cpu));
> + return 0;
> +}
> +
> +char _license[] SEC("license") = "GPL";
> +__u32 _version SEC("version") = 1;
>
^ 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