* [PATCH net v2 0/2] selftests: pmtu: fix and increase coverage
From: Paolo Abeni @ 2019-02-25 11:13 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, David Ahern, Stefano Brivio
This series includes a fixup for the pmtu.sh test script, related to IPv6
address management, and adds coverage for the recently reported and fixed
PMTU exception issue
v1 -> v2:
- several script cleanups
Paolo Abeni (2):
selftests: pmtu: disable DAD in all namespaces
selftests: pmtu: add explicit tests for PMTU exceptions cleanup
tools/testing/selftests/net/pmtu.sh | 95 ++++++++++++++++++++++++-----
1 file changed, 79 insertions(+), 16 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH net v2 2/2] selftests: pmtu: add explicit tests for PMTU exceptions cleanup
From: Paolo Abeni @ 2019-02-25 11:13 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, David Ahern, Stefano Brivio
In-Reply-To: <cover.1551093086.git.pabeni@redhat.com>
Add a couple of new tests, explicitly checking that the kernel
timely releases PMTU exceptions on related device removal.
This is mostly a regression test vs the issue fixed by
commit f5b51fe804ec ("ipv6: route: purge exception on removal")
Only 2 new test cases have been added, instead of extending all
the existing ones, because the reproducer requires executing
several commands and would slow down too much the tests otherwise.
v1 -> v2:
- several script cleanups, as suggested by Stefano
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
---
tools/testing/selftests/net/pmtu.sh | 67 ++++++++++++++++++++++++++++-
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/pmtu.sh b/tools/testing/selftests/net/pmtu.sh
index 89aec2fdf4fa..be0491c3acad 100755
--- a/tools/testing/selftests/net/pmtu.sh
+++ b/tools/testing/selftests/net/pmtu.sh
@@ -103,6 +103,15 @@
# and check that configured MTU is used on link creation and changes, and
# that MTU is properly calculated instead when MTU is not configured from
# userspace
+#
+# - pmtu_ipv4_exception_cleanup
+# Similar to pmtu_ipv4_vxlan4_exception, but explicitly generate PMTU
+# exceptions on multiple CPUs and check that the veth device tear-down
+# happens in a timely manner
+#
+# - pmtu_ipv6_exception_cleanup
+# Same as above, but use IPv6 transport from A to B
+
# Kselftest framework requirement - SKIP code is 4.
ksft_skip=4
@@ -135,7 +144,9 @@ tests="
pmtu_vti6_default_mtu vti6: default MTU assignment
pmtu_vti4_link_add_mtu vti4: MTU setting on link creation
pmtu_vti6_link_add_mtu vti6: MTU setting on link creation
- pmtu_vti6_link_change_mtu vti6: MTU changes on link changes"
+ pmtu_vti6_link_change_mtu vti6: MTU changes on link changes
+ pmtu_ipv4_exception_cleanup ipv4: cleanup of cached exceptions
+ pmtu_ipv6_exception_cleanup ipv6: cleanup of cached exceptions"
NS_A="ns-$(mktemp -u XXXXXX)"
NS_B="ns-$(mktemp -u XXXXXX)"
@@ -1006,6 +1017,60 @@ test_pmtu_vti6_link_change_mtu() {
return ${fail}
}
+chk_command() {
+ cmd=${1}
+
+ if ! which ${cmd} > /dev/null 2>&1; then
+ err " missing required command: '${cmd}'"
+ return 1
+ fi
+ return 0
+}
+
+test_cleanup_vxlanX_exception() {
+ outer="${1}"
+ encap="vxlan"
+ ll_mtu=4000
+
+ chk_command taskset || return 2
+ chk_command timeout || return 2
+ cpu_list=$(grep -m 2 processor /proc/cpuinfo | cut -d ' ' -f 2)
+
+ setup namespaces routing ${encap}${outer} || return 2
+ trace "${ns_a}" ${encap}_a "${ns_b}" ${encap}_b \
+ "${ns_a}" veth_A-R1 "${ns_r1}" veth_R1-A \
+ "${ns_b}" veth_B-R1 "${ns_r1}" veth_R1-B
+
+ # Create route exception by exceeding link layer MTU
+ mtu "${ns_a}" veth_A-R1 $((${ll_mtu} + 1000))
+ mtu "${ns_r1}" veth_R1-A $((${ll_mtu} + 1000))
+ mtu "${ns_b}" veth_B-R1 ${ll_mtu}
+ mtu "${ns_r1}" veth_R1-B ${ll_mtu}
+
+ mtu "${ns_a}" ${encap}_a $((${ll_mtu} + 1000))
+ mtu "${ns_b}" ${encap}_b $((${ll_mtu} + 1000))
+
+ # Fill exception cache for multiple CPUs (2)
+ # we can always use inner IPv4 for that
+ for cpu in ${cpu_list}; do
+ taskset --cpu-list ${cpu} ${ns_a} ping -q -M want -i 0.1 -w 1 -s $((${ll_mtu} + 500)) ${tunnel4_b_addr} > /dev/null
+ done
+
+ if ! timeout 1 ${ns_a} ip link del dev veth_A-R1; then
+ err " can't delete veth device in a timely manner, PMTU dst likely leaked"
+ return 1
+ fi
+ return 0
+}
+
+test_pmtu_ipv6_exception_cleanup() {
+ test_cleanup_vxlanX_exception 6 vxlan
+}
+
+test_pmtu_ipv4_exception_cleanup() {
+ test_cleanup_vxlanX_exception 4 vxlan
+}
+
usage() {
echo
echo "$0 [OPTIONS] [TEST]..."
--
2.20.1
^ permalink raw reply related
* [PATCH net v2 1/2] selftests: pmtu: disable DAD in all namespaces
From: Paolo Abeni @ 2019-02-25 11:13 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, David Ahern, Stefano Brivio
In-Reply-To: <cover.1551093086.git.pabeni@redhat.com>
Otherwise, the configured IPv6 address could be still "tentative"
at test time, possibly causing tests failures.
We can also drop some sleep along the code and decrease the
timeout for most commands so that the test runtime decreases.
v1 -> v2:
- fix comment (Stefano)
Fixes: d1f1b9cbf34c ("selftests: net: Introduce first PMTU test")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: David Ahern <dsahern@gmail.com>
---
tools/testing/selftests/net/pmtu.sh | 28 +++++++++++++---------------
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/tools/testing/selftests/net/pmtu.sh b/tools/testing/selftests/net/pmtu.sh
index e2c94e47707c..89aec2fdf4fa 100755
--- a/tools/testing/selftests/net/pmtu.sh
+++ b/tools/testing/selftests/net/pmtu.sh
@@ -263,8 +263,6 @@ setup_fou_or_gue() {
${ns_a} ip link set ${encap}_a up
${ns_b} ip link set ${encap}_b up
-
- sleep 1
}
setup_fou44() {
@@ -302,6 +300,10 @@ setup_gue66() {
setup_namespaces() {
for n in ${NS_A} ${NS_B} ${NS_R1} ${NS_R2}; do
ip netns add ${n} || return 1
+
+ # Disable DAD, so that we don't have to wait to use the
+ # configured IPv6 addresses
+ ip netns exec ${n} sysctl -q net/ipv6/conf/default/accept_dad=0
done
}
@@ -337,8 +339,6 @@ setup_vti() {
${ns_a} ip link set vti${proto}_a up
${ns_b} ip link set vti${proto}_b up
-
- sleep 1
}
setup_vti4() {
@@ -375,8 +375,6 @@ setup_vxlan_or_geneve() {
${ns_a} ip link set ${type}_a up
${ns_b} ip link set ${type}_b up
-
- sleep 1
}
setup_geneve4() {
@@ -588,8 +586,8 @@ test_pmtu_ipvX() {
mtu "${ns_b}" veth_B-R2 1500
# Create route exceptions
- ${ns_a} ${ping} -q -M want -i 0.1 -w 2 -s 1800 ${dst1} > /dev/null
- ${ns_a} ${ping} -q -M want -i 0.1 -w 2 -s 1800 ${dst2} > /dev/null
+ ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s 1800 ${dst1} > /dev/null
+ ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s 1800 ${dst2} > /dev/null
# Check that exceptions have been created with the correct PMTU
pmtu_1="$(route_get_dst_pmtu_from_exception "${ns_a}" ${dst1})"
@@ -621,7 +619,7 @@ test_pmtu_ipvX() {
# Decrease remote MTU on path via R2, get new exception
mtu "${ns_r2}" veth_R2-B 400
mtu "${ns_b}" veth_B-R2 400
- ${ns_a} ${ping} -q -M want -i 0.1 -w 2 -s 1400 ${dst2} > /dev/null
+ ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s 1400 ${dst2} > /dev/null
pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" ${dst2})"
check_pmtu_value "lock 552" "${pmtu_2}" "exceeding MTU, with MTU < min_pmtu" || return 1
@@ -638,7 +636,7 @@ test_pmtu_ipvX() {
check_pmtu_value "1500" "${pmtu_2}" "increasing local MTU" || return 1
# Get new exception
- ${ns_a} ${ping} -q -M want -i 0.1 -w 2 -s 1400 ${dst2} > /dev/null
+ ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s 1400 ${dst2} > /dev/null
pmtu_2="$(route_get_dst_pmtu_from_exception "${ns_a}" ${dst2})"
check_pmtu_value "lock 552" "${pmtu_2}" "exceeding MTU, with MTU < min_pmtu" || return 1
}
@@ -687,7 +685,7 @@ test_pmtu_ipvX_over_vxlanY_or_geneveY_exception() {
mtu "${ns_a}" ${type}_a $((${ll_mtu} + 1000))
mtu "${ns_b}" ${type}_b $((${ll_mtu} + 1000))
- ${ns_a} ${ping} -q -M want -i 0.1 -w 2 -s $((${ll_mtu} + 500)) ${dst} > /dev/null
+ ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s $((${ll_mtu} + 500)) ${dst} > /dev/null
# Check that exception was created
pmtu="$(route_get_dst_pmtu_from_exception "${ns_a}" ${dst})"
@@ -767,7 +765,7 @@ test_pmtu_ipvX_over_fouY_or_gueY() {
mtu "${ns_a}" ${encap}_a $((${ll_mtu} + 1000))
mtu "${ns_b}" ${encap}_b $((${ll_mtu} + 1000))
- ${ns_a} ${ping} -q -M want -i 0.1 -w 2 -s $((${ll_mtu} + 500)) ${dst} > /dev/null
+ ${ns_a} ${ping} -q -M want -i 0.1 -w 1 -s $((${ll_mtu} + 500)) ${dst} > /dev/null
# Check that exception was created
pmtu="$(route_get_dst_pmtu_from_exception "${ns_a}" ${dst})"
@@ -825,13 +823,13 @@ test_pmtu_vti4_exception() {
# Send DF packet without exceeding link layer MTU, check that no
# exception is created
- ${ns_a} ping -q -M want -i 0.1 -w 2 -s ${ping_payload} ${tunnel4_b_addr} > /dev/null
+ ${ns_a} ping -q -M want -i 0.1 -w 1 -s ${ping_payload} ${tunnel4_b_addr} > /dev/null
pmtu="$(route_get_dst_pmtu_from_exception "${ns_a}" ${tunnel4_b_addr})"
check_pmtu_value "" "${pmtu}" "sending packet smaller than PMTU (IP payload length ${esp_payload_rfc4106})" || return 1
# Now exceed link layer MTU by one byte, check that exception is created
# with the right PMTU value
- ${ns_a} ping -q -M want -i 0.1 -w 2 -s $((ping_payload + 1)) ${tunnel4_b_addr} > /dev/null
+ ${ns_a} ping -q -M want -i 0.1 -w 1 -s $((ping_payload + 1)) ${tunnel4_b_addr} > /dev/null
pmtu="$(route_get_dst_pmtu_from_exception "${ns_a}" ${tunnel4_b_addr})"
check_pmtu_value "${esp_payload_rfc4106}" "${pmtu}" "exceeding PMTU (IP payload length $((esp_payload_rfc4106 + 1)))"
}
@@ -847,7 +845,7 @@ test_pmtu_vti6_exception() {
mtu "${ns_b}" veth_b 4000
mtu "${ns_a}" vti6_a 5000
mtu "${ns_b}" vti6_b 5000
- ${ns_a} ${ping6} -q -i 0.1 -w 2 -s 60000 ${tunnel6_b_addr} > /dev/null
+ ${ns_a} ${ping6} -q -i 0.1 -w 1 -s 60000 ${tunnel6_b_addr} > /dev/null
# Check that exception was created
pmtu="$(route_get_dst_pmtu_from_exception "${ns_a}" ${tunnel6_b_addr})"
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net] ipv4: Add ICMPv6 support when parse route ipproto
From: Sabrina Dubroca @ 2019-02-25 11:14 UTC (permalink / raw)
To: Hangbin Liu; +Cc: netdev, Roopa Prabhu, David S . Miller
In-Reply-To: <20190225074700.7316-1-liuhangbin@gmail.com>
2019-02-25, 15:47:00 +0800, Hangbin Liu wrote:
> @@ -14,6 +15,7 @@ int rtm_getroute_parse_ip_proto(struct nlattr *attr, u8 *ip_proto,
> case IPPROTO_TCP:
> case IPPROTO_UDP:
> case IPPROTO_ICMP:
> + case IPPROTO_ICMPV6:
Is IPPROTO_ICMPV6 supposed to be valid in the IPv4 code path calling
this function? inet_rtm_getroute_build_skb() doesn't seem to handle
it. Likewise, userspace could pass IPPROTO_ICMP from the IPv6 caller.
Also, should that be guarded by #if IS_ENABLED(CONFIG_IPV6) ?
> return 0;
> default:
> NL_SET_ERR_MSG(extack, "Unsupported ip proto");
> --
> 2.19.2
>
--
Sabrina
^ permalink raw reply
* Re: [PATCH v2 bpf-next 4/4] tools/bpftool: recognize bpf_prog_info runtime and runcnt
From: Daniel Borkmann @ 2019-02-25 11:17 UTC (permalink / raw)
To: Alexei Starovoitov, davem; +Cc: edumazet, netdev, bpf, kernel-team
In-Reply-To: <20190223174422.663270-5-ast@kernel.org>
On 02/23/2019 06:44 PM, Alexei Starovoitov wrote:
> $ bpftool p s
> 1: kprobe tag a56587d488d216c9 gpl runtime 79786 runcnt 8
> loaded_at 2019-02-22T12:22:51-0800 uid 0
> xlated 352B not jited memlock 4096B
>
> $ bpftool --json --pretty p s
> [{
> "id": 1,
> "type": "kprobe",
> "tag": "a56587d488d216c9",
> "gpl_compatible": true,
> "run_time_ns": 79786,
> "run_cnt": 8,
> "loaded_at": 1550866971,
> "uid": 0,
> "bytes_xlated": 352,
> "jited": false,
> "bytes_memlock": 4096
> }
> ]
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
> tools/bpf/bpftool/Documentation/bpftool-prog.rst | 4 +++-
> tools/bpf/bpftool/prog.c | 7 +++++++
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/tools/bpf/bpftool/Documentation/bpftool-prog.rst b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
> index 12bc1e2d4b46..d8b46a8f17e0 100644
> --- a/tools/bpf/bpftool/Documentation/bpftool-prog.rst
> +++ b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
> @@ -171,7 +171,7 @@ EXAMPLES
>
> ::
>
> - 10: xdp name some_prog tag 005a3d2123620c8b gpl
> + 10: xdp name some_prog tag 005a3d2123620c8b gpl runtime 81632 runcnt 10
> loaded_at 2017-09-29T20:11:00+0000 uid 0
> xlated 528B jited 370B memlock 4096B map_ids 10
>
> @@ -184,6 +184,8 @@ EXAMPLES
> "type": "xdp",
> "tag": "005a3d2123620c8b",
> "gpl_compatible": true,
> + "run_time_ns": 81632,
> + "run_cnt": 10,
> "loaded_at": 1506715860,
> "uid": 0,
> "bytes_xlated": 528,
> diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
> index db978c8d76a8..cdb6bd424340 100644
> --- a/tools/bpf/bpftool/prog.c
> +++ b/tools/bpf/bpftool/prog.c
> @@ -214,6 +214,10 @@ static void print_prog_json(struct bpf_prog_info *info, int fd)
> info->tag[4], info->tag[5], info->tag[6], info->tag[7]);
>
> jsonw_bool_field(json_wtr, "gpl_compatible", info->gpl_compatible);
> + if (info->runtime) {
> + jsonw_uint_field(json_wtr, "run_time_ns", info->runtime);
> + jsonw_uint_field(json_wtr, "run_cnt", info->runcnt);
Didn't Andrii mean to generally name these fields run_time_ns and run_cnt, so also
uapi aside from just changing bpftool output (why keeping these names not the same)?
> + }
>
> print_dev_json(info->ifindex, info->netns_dev, info->netns_ino);
>
> @@ -277,6 +281,9 @@ static void print_prog_plain(struct bpf_prog_info *info, int fd)
> fprint_hex(stdout, info->tag, BPF_TAG_SIZE, "");
> print_dev_plain(info->ifindex, info->netns_dev, info->netns_ino);
> printf("%s", info->gpl_compatible ? " gpl" : "");
> + if (info->runtime)
> + printf(" runtime %lld runcnt %lld",
> + info->runtime, info->runcnt);
> printf("\n");
>
> if (info->load_time) {
>
^ permalink raw reply
* Re: [PATCH net-next] mlxsw: spectrum: remove set but not used variable 'autoneg_status'
From: Ido Schimmel @ 2019-02-25 11:18 UTC (permalink / raw)
To: YueHaibing
Cc: Jiri Pirko, davem@davemloft.net, netdev@vger.kernel.org,
kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190225020328.42510-1-yuehaibing@huawei.com>
On Mon, Feb 25, 2019 at 02:03:28AM +0000, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/mellanox/mlxsw/spectrum.c: In function 'mlxsw_sp_port_get_link_ksettings':
> drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3062:5: warning:
> variable 'autoneg_status' set but not used [-Wunused-but-set-variable]
>
> It's not used since commit 475b33cb66c9 ("mlxsw: spectrum: Remove unsupported
> eth_proto_lp_advertise field in PTYS")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Thanks!
^ permalink raw reply
* [PATCH net] sctp: get sctphdr by offset in sctp_compute_cksum
From: Xin Long @ 2019-02-25 11:25 UTC (permalink / raw)
To: linux-kernel, network dev, linux-sctp
Cc: davem, Marcelo Ricardo Leitner, Neil Horman
sctp_hdr(skb) only works when skb->transport_header is set properly.
But in the path of nf_conntrack_in: sctp_packet() -> sctp_error()
skb->transport_header is not guaranteed to be right value for sctp.
It will cause to fail to check the checksum for sctp packets.
So fix it by using offset, which is always right in all places.
Fixes: e6d8b64b34aa ("net: sctp: fix and consolidate SCTP checksumming code")
Reported-by: Li Shuang <shuali@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
include/net/sctp/checksum.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/sctp/checksum.h b/include/net/sctp/checksum.h
index 32ee65a..1c6e6c0 100644
--- a/include/net/sctp/checksum.h
+++ b/include/net/sctp/checksum.h
@@ -61,7 +61,7 @@ static inline __wsum sctp_csum_combine(__wsum csum, __wsum csum2,
static inline __le32 sctp_compute_cksum(const struct sk_buff *skb,
unsigned int offset)
{
- struct sctphdr *sh = sctp_hdr(skb);
+ struct sctphdr *sh = (struct sctphdr *)(skb->data + offset);
const struct skb_checksum_ops ops = {
.update = sctp_csum_update,
.combine = sctp_csum_combine,
--
2.1.0
^ permalink raw reply related
* [PATCH net] ipvs: get sctphdr by sctphoff in sctp_csum_check
From: Xin Long @ 2019-02-25 11:27 UTC (permalink / raw)
To: network dev, netfilter-devel; +Cc: Marcelo Ricardo Leitner, Neil Horman, pablo
sctp_csum_check() is called by sctp_s/dnat_handler() where it calls
skb_make_writable() to ensure sctphdr to be linearized.
So there's no need to get sctphdr by calling skb_header_pointer()
in sctp_csum_check().
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/netfilter/ipvs/ip_vs_proto_sctp.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_proto_sctp.c b/net/netfilter/ipvs/ip_vs_proto_sctp.c
index b0cd7d0..0ecf241 100644
--- a/net/netfilter/ipvs/ip_vs_proto_sctp.c
+++ b/net/netfilter/ipvs/ip_vs_proto_sctp.c
@@ -183,7 +183,7 @@ static int
sctp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp)
{
unsigned int sctphoff;
- struct sctphdr *sh, _sctph;
+ struct sctphdr *sh;
__le32 cmp, val;
#ifdef CONFIG_IP_VS_IPV6
@@ -193,10 +193,7 @@ sctp_csum_check(int af, struct sk_buff *skb, struct ip_vs_protocol *pp)
#endif
sctphoff = ip_hdrlen(skb);
- sh = skb_header_pointer(skb, sctphoff, sizeof(_sctph), &_sctph);
- if (sh == NULL)
- return 0;
-
+ sh = (struct sctphdr *)(skb->data + sctphoff);
cmp = sh->checksum;
val = sctp_compute_cksum(skb, sctphoff);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net v2 2/2] selftests: pmtu: add explicit tests for PMTU exceptions cleanup
From: Stefano Brivio @ 2019-02-25 11:35 UTC (permalink / raw)
To: Paolo Abeni; +Cc: netdev, David S. Miller, David Ahern
In-Reply-To: <6d6f6a2512743d6e1968dbfe765eb85b478bd033.1551093086.git.pabeni@redhat.com>
Just three minor details, feel free to ignore:
On Mon, 25 Feb 2019 12:13:46 +0100
Paolo Abeni <pabeni@redhat.com> wrote:
> @@ -1006,6 +1017,60 @@ test_pmtu_vti6_link_change_mtu() {
> return ${fail}
> }
>
> +chk_command() {
All the other functions checking something are called 'check_*'.
> + cmd=${1}
> +
> + if ! which ${cmd} > /dev/null 2>&1; then
> + err " missing required command: '${cmd}'"
> + return 1
> + fi
> + return 0
> +}
> +
> +test_cleanup_vxlanX_exception() {
> + outer="${1}"
> + encap="vxlan"
> + ll_mtu=4000
> +
> + chk_command taskset || return 2
> + chk_command timeout || return 2
> + cpu_list=$(grep -m 2 processor /proc/cpuinfo | cut -d ' ' -f 2)
> +
> + setup namespaces routing ${encap}${outer} || return 2
> + trace "${ns_a}" ${encap}_a "${ns_b}" ${encap}_b \
> + "${ns_a}" veth_A-R1 "${ns_r1}" veth_R1-A \
> + "${ns_b}" veth_B-R1 "${ns_r1}" veth_R1-B
> +
> + # Create route exception by exceeding link layer MTU
> + mtu "${ns_a}" veth_A-R1 $((${ll_mtu} + 1000))
> + mtu "${ns_r1}" veth_R1-A $((${ll_mtu} + 1000))
> + mtu "${ns_b}" veth_B-R1 ${ll_mtu}
> + mtu "${ns_r1}" veth_R1-B ${ll_mtu}
> +
> + mtu "${ns_a}" ${encap}_a $((${ll_mtu} + 1000))
> + mtu "${ns_b}" ${encap}_b $((${ll_mtu} + 1000))
> +
> + # Fill exception cache for multiple CPUs (2)
> + # we can always use inner IPv4 for that
> + for cpu in ${cpu_list}; do
> + taskset --cpu-list ${cpu} ${ns_a} ping -q -M want -i 0.1 -w 1 -s $((${ll_mtu} + 500)) ${tunnel4_b_addr} > /dev/null
> + done
> +
> + if ! timeout 1 ${ns_a} ip link del dev veth_A-R1; then
> + err " can't delete veth device in a timely manner, PMTU dst likely leaked"
> + return 1
> + fi
> + return 0
No need for explicit return 0.
> +}
> +
> +test_pmtu_ipv6_exception_cleanup() {
> + test_cleanup_vxlanX_exception 6 vxlan
> +}
> +
> +test_pmtu_ipv4_exception_cleanup() {
> + test_cleanup_vxlanX_exception 4 vxlan
This function now takes just one argument.
--
Stefano
^ permalink raw reply
* [PATCH net-next resend 0/2]
From: Marek Behún @ 2019-02-25 11:39 UTC (permalink / raw)
To: netdev; +Cc: Andrew Lunn, Florian Fainelli, David Miller
Hi,
this is a rebased resend of patches I sent one month ago.
I added Reviewed-by tags by Andrew and Florian.
Marek
^ permalink raw reply
* [PATCH net-next resend 1/2] net: dsa: mv88e6xxx: Default CMODE to 1000BaseX only on 6390X
From: Marek Behún @ 2019-02-25 11:39 UTC (permalink / raw)
To: netdev; +Cc: Andrew Lunn, Florian Fainelli, David Miller, Marek Behún
In-Reply-To: <20190225113955.25700-1-marek.behun@nic.cz>
Commit 787799a9d555 sets the SERDES interfaces of 6390 and 6390X to
1000BaseX, but this is only needed on 6390X, since there are SERDES
interfaces which can be used on lower ports on 6390.
This commit fixes this by returning to previous behaviour on 6390.
(Previous behaviour means that CMODE is not set at all if requested mode
is NA).
This is needed on Turris MOX, where the 88e6190 is connected to CPU in
2500BaseX mode.
Fixes: 787799a9d555 ("net: dsa: mv88e6xxx: Default ports 9/10 6390X CMODE to 1000BaseX")
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/mv88e6xxx/port.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index ebd26b6a93e6..ee7029f4ee22 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -444,6 +444,8 @@ int mv88e6390_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
phy_interface_t mode)
{
switch (mode) {
+ case PHY_INTERFACE_MODE_NA:
+ return 0;
case PHY_INTERFACE_MODE_XGMII:
case PHY_INTERFACE_MODE_XAUI:
case PHY_INTERFACE_MODE_RXAUI:
--
2.19.2
^ permalink raw reply related
* [PATCH net-next resend 2/2] net: dsa: mv88e6xxx: Fix phylink_validate for Topaz family
From: Marek Behún @ 2019-02-25 11:39 UTC (permalink / raw)
To: netdev; +Cc: Andrew Lunn, Florian Fainelli, David Miller, Marek Behún
In-Reply-To: <20190225113955.25700-1-marek.behun@nic.cz>
The Topaz family should have different phylink_validate method from the
Peridot, since on Topaz the port supporting 2500BaseX mode is port 5,
not 9 and 10.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6xxx/chip.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index d30336f259ce..f223e6476369 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -658,6 +658,20 @@ static void mv88e6185_phylink_validate(struct mv88e6xxx_chip *chip, int port,
mv88e6065_phylink_validate(chip, port, mask, state);
}
+static void mv88e6341_phylink_validate(struct mv88e6xxx_chip *chip, int port,
+ unsigned long *mask,
+ struct phylink_link_state *state)
+{
+ if (port >= 5)
+ phylink_set(mask, 2500baseX_Full);
+
+ /* No ethtool bits for 200Mbps */
+ phylink_set(mask, 1000baseT_Full);
+ phylink_set(mask, 1000baseX_Full);
+
+ mv88e6065_phylink_validate(chip, port, mask, state);
+}
+
static void mv88e6352_phylink_validate(struct mv88e6xxx_chip *chip, int port,
unsigned long *mask,
struct phylink_link_state *state)
@@ -3080,7 +3094,7 @@ static const struct mv88e6xxx_ops mv88e6141_ops = {
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
.serdes_power = mv88e6341_serdes_power,
.gpio_ops = &mv88e6352_gpio_ops,
- .phylink_validate = mv88e6390_phylink_validate,
+ .phylink_validate = mv88e6341_phylink_validate,
};
static const struct mv88e6xxx_ops mv88e6161_ops = {
@@ -3712,7 +3726,7 @@ static const struct mv88e6xxx_ops mv88e6341_ops = {
.gpio_ops = &mv88e6352_gpio_ops,
.avb_ops = &mv88e6390_avb_ops,
.ptp_ops = &mv88e6352_ptp_ops,
- .phylink_validate = mv88e6390_phylink_validate,
+ .phylink_validate = mv88e6341_phylink_validate,
};
static const struct mv88e6xxx_ops mv88e6350_ops = {
--
2.19.2
^ permalink raw reply related
* Re: [PATCH ethtool] ethtool: Add support for 200Gbps (50Gbps per lane) link mode
From: Michal Kubecek @ 2019-02-25 11:48 UTC (permalink / raw)
To: Tariq Toukan; +Cc: John W. Linville, netdev, Eran Ben Elisha, Aya Levin
In-Reply-To: <20190224181104.GA1914@unicorn.suse.cz>
On Sun, Feb 24, 2019 at 07:11:04PM +0100, Michal Kubecek wrote:
> On Sun, Feb 24, 2019 at 05:08:21PM +0200, Tariq Toukan wrote:
> > From: Aya Levin <ayal@mellanox.com>
> >
> > Introduce 50Gbps per lane link modes and 200Gbps speed, update print
> > functions and initialization functions accordingly.
> > In addition, update related man page accordingly.
> >
> > Signed-off-by: Aya Levin <ayal@mellanox.com>
> > Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> > ---
> > ethtool-copy.h | 19 ++++++++++++++++++-
> > ethtool.8.in | 15 +++++++++++++++
> > ethtool.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 85 insertions(+), 1 deletion(-)
> >
> > diff --git a/ethtool-copy.h b/ethtool-copy.h
> > index 6bfbb85f9402..de459900b2d3 100644
> > --- a/ethtool-copy.h
> > +++ b/ethtool-copy.h
> > @@ -1455,15 +1455,31 @@ enum ethtool_link_mode_bit_indices {
> > ETHTOOL_LINK_MODE_FEC_NONE_BIT = 49,
> > ETHTOOL_LINK_MODE_FEC_RS_BIT = 50,
> > ETHTOOL_LINK_MODE_FEC_BASER_BIT = 51,
> > + ETHTOOL_LINK_MODE_50000baseKR_Full_BIT = 52,
> > + ETHTOOL_LINK_MODE_50000baseSR_Full_BIT = 53,
> > + ETHTOOL_LINK_MODE_50000baseCR_Full_BIT = 54,
> > + ETHTOOL_LINK_MODE_50000baseLR_ER_FR_Full_BIT = 55,
> > + ETHTOOL_LINK_MODE_50000baseDR_Full_BIT = 56,
> > + ETHTOOL_LINK_MODE_100000baseKR2_Full_BIT = 57,
> > + ETHTOOL_LINK_MODE_100000baseSR2_Full_BIT = 58,
> > + ETHTOOL_LINK_MODE_100000baseCR2_Full_BIT = 59,
> > + ETHTOOL_LINK_MODE_100000baseLR2_ER2_FR2_Full_BIT = 60,
> > + ETHTOOL_LINK_MODE_100000baseDR2_Full_BIT = 61,
> > + ETHTOOL_LINK_MODE_200000baseKR4_Full_BIT = 62,
> > + ETHTOOL_LINK_MODE_200000baseSR4_Full_BIT = 63,
> > + ETHTOOL_LINK_MODE_200000baseLR4_ER4_FR4_Full_BIT = 64,
> > + ETHTOOL_LINK_MODE_200000baseDR4_Full_BIT = 65,
> > + ETHTOOL_LINK_MODE_200000baseCR4_Full_BIT = 66,
> >
> > /* Last allowed bit for __ETHTOOL_LINK_MODE_LEGACY_MASK is bit
> > * 31. Please do NOT define any SUPPORTED_* or ADVERTISED_*
> > * macro for bits > 31. The only way to use indices > 31 is to
> > * use the new ETHTOOL_GLINKSETTINGS/ETHTOOL_SLINKSETTINGS API.
> > */
> > + ETHTOOL_LINK_MODE_LAST,
> >
> > __ETHTOOL_LINK_MODE_LAST
> > - = ETHTOOL_LINK_MODE_FEC_BASER_BIT,
> > + = ETHTOOL_LINK_MODE_LAST - 1,
> > };
>
> The name ETHTOOL_LINK_MODE_LAST is a bit misleading, maybe it should
> rather be called ETHTOOL_LINK_MODE_COUNT. Also, there should be
> parentheses around the expression to avoid surprises when
> __ETHTOOL_LINK_MODE_LAST is used in an expression.
>
> But this change is not in kernel include/uapi/linux/ethtool.h in
> mainline, net or net-next. As ethtool-copy.h is supposed to be a copy of
> sanitized kernel uapi header, you should make the change there first and
> then sync the header to ethtool.
For the record, net-next tree now has simplified this even more with
commit e728fdf06289 ("net: phy: improve definition of
__ETHTOOL_LINK_MODE_MASK_NBITS").
Michal Kubecek
^ permalink raw reply
* Re: 32-bit Amlogic SoCs: avoid using Ethernet MAC addresses
From: Anand Moon @ 2019-02-25 12:19 UTC (permalink / raw)
To: Martin Blumenstingl, Bartosz Golaszewski; +Cc: linux-amlogic, netdev
In-Reply-To: <CAFBinCDRKJS-RXgVBDo2gjp_bU8Wmbhr+HGXNad4vCFyrvN_HA@mail.gmail.com>
hi Martin,
+Bartosz Golaszewski <bgolaszewski@baylibre.com>
On Mon, 25 Feb 2019 at 02:25, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
>
> I have seen Anand's your question in [0]:
> > only issue is I have is the each time their is random MAC address so I
> > get new IP from dhcp server.
> > How can I avoid this. I have tried to enable eFuse driver but with no success.
>
> u-boot on the 64-bit SoCs can read the MAC address from the eFuse and
> pass it (via the .dtb) to the kernel.
> This requires an ethernet0 alias in the mainline .dts though, see [1]
> for and example.
>
> I'm not sure if this also works with the older u-boot on the 32-bit SoCs.
> if it doesn't then there's a nvmem-cells binding for all Ethernet
> controllers: [2] (please note that the function implementing this
> binding was recently renamed: [3])
> as far as I can tell the stmmac driver doesn't support the nvmem-cells
> based binding yet
>
> Anand, if you want to work on this: feel free to do so!
> I have the SDHC MMC driver and a discussion about the power-domain
> drivers on my TODO-list, so I'm pretty busy at the moment.
>
>
> Regards
> Martin
>
Thanks for your inputs :) 8)
After enable CONFIG_MESON_MX_EFUSE and added the alias
On Odroid C1+
# hexdump /sys/devices/platform/soc/da000000.secbus/da000000.nvmem/meson8b-efuse0/nvmem
0000000 1143 0000 4b48 3143 3131 3232 3346 4537
0000010 3942 4432 0000 0000 0000 0000 0000 0000
0000020 0000 0000 0000 0000 0000 0000 0000 0000
*
00001b0 0000 0000 1e00 1006 addc 0000 0000 0000 *00:1e:06:10:dc:ad*
mac address from nvmem
00001c0 0000 0000 0000 4b48 3143 3133 3631 3131
00001d0 3732 3130 6237 6537 3165 6437 3034 3764
00001e0 02ad ec24 ff7f acfb d692 5300 0047 0000
00001f0 0000 0000 0000 aff6 a000 0000 1400 c100
0000200
as per my understating on 3.10.x the mac address is also set in the u-boot env.
odroidc#printenv ethaddr
ethaddr=00:1e:06:10:dc:ad
Which is equal to above nvmem setting above.
* But sill I am getting new mac address on every reboot. :p *
Odroid C2:
I could clearly observe the same.
[root@archl-c2l alarm]# hexdump /sys/devices/platform/efuse/efuse0/nvmem
0000000 0000 0000 0000 0000 0000 0000 0000 0000
0000010 0000 0000 4b48 3243 3331 3532 4434 4346
0000020 4145 4146 0000 0000 0000 0000 0000 0000
0000030 0000 0000 1e00 3306 7a37 0000 0000 0000 *00:1e:06:33:37:7a*
0000040 0000 0000 0000 4b48 3243 3132 3631 3430
0000050 3834 3932 3631 3837 3937 3466 6233 6366
0000060 357c c7ec cc98 0f6d 65b7 92cf 000b 0a00
0000070 0000 0000 0000 0000 0000 0000 0000 0000
0000080 0014 0000 0000 0000 0000 0000 0000 0000
0000090 0000 0000 0000 0000 0000 0000 0000 0000
*
00000c0
[root@archl-c2l alarm]# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.140 netmask 255.255.255.0 broadcast 10.0.0.255
inet6 2002:ac10:e303:e472:21e:6ff:fe33:377a prefixlen 64
scopeid 0x0<global>
inet6 fe80::21e:6ff:fe33:377a prefixlen 64 scopeid 0x20<link>
ether 00:1e:06:33:37:7a txqueuelen 1000 (Ethernet)
RX packets 70485 bytes 4390622 (4.1 MiB)
RX errors 0 dropped 28 overruns 0 frame 0
TX packets 6159 bytes 766939 (748.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18
How can we read the mac address from given offset in nvmem.
>
> [0] http://lists.infradead.org/pipermail/linux-amlogic/2019-February/010464.html
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7c36209c46c4d162202b65eed2e66962ad8c3c1
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9217e566bdee4583d0a9ea4879c8f5e004886eac
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=afa64a72b862a7a9d04f8d07fba632eaf06b23f8
Yes thanks for the inputs.
I see c85efcc60a892210aa10688d5de1f997d5cad799 ("ARM: davinci:
da830-evm: use cell nvmem lookup for mac address")
I do not know what this changes will help get the mac address from nvmem region.
If some body could share some inputs it will be better for me to debug.
Best Regards
-Anand
^ permalink raw reply
* [PATCH net-next] net: sched: act_tunnel_key: fix metadata handling
From: Vlad Buslov @ 2019-02-25 12:21 UTC (permalink / raw)
To: netdev; +Cc: jhs, xiyou.wangcong, jiri, davem, dcaratti, wenxu, roid,
Vlad Buslov
Tunnel key action params->tcft_enc_metadata is only set when action is
TCA_TUNNEL_KEY_ACT_SET. However, metadata pointer is incorrectly
dereferenced during tunnel key init and release without verifying that
action is if correct type, which causes NULL pointer dereference. Metadata
tunnel dst_cache is also leaked on action overwrite.
Fix metadata handling:
- Verify that metadata pointer is not NULL before dereferencing it in
tunnel_key_init error handling code.
- Move dst_cache destroy code into tunnel_key_release_params() function
that is called in both action overwrite and release cases (fixes resource
leak) and verifies that actions has correct type before dereferencing
metadata pointer (fixes NULL pointer dereference).
Oops with KASAN enabled during tdc tests execution:
[ 261.080482] ==================================================================
[ 261.088049] BUG: KASAN: null-ptr-deref in dst_cache_destroy+0x21/0xa0
[ 261.094613] Read of size 8 at addr 00000000000000b0 by task tc/2976
[ 261.102524] CPU: 14 PID: 2976 Comm: tc Not tainted 5.0.0-rc7+ #157
[ 261.108844] Hardware name: Supermicro SYS-2028TP-DECR/X10DRT-P, BIOS 2.0b 03/30/2017
[ 261.116726] Call Trace:
[ 261.119234] dump_stack+0x9a/0xeb
[ 261.122625] ? dst_cache_destroy+0x21/0xa0
[ 261.126818] ? dst_cache_destroy+0x21/0xa0
[ 261.131004] kasan_report+0x176/0x192
[ 261.134752] ? idr_get_next+0xd0/0x120
[ 261.138578] ? dst_cache_destroy+0x21/0xa0
[ 261.142768] dst_cache_destroy+0x21/0xa0
[ 261.146799] tunnel_key_release+0x3a/0x50 [act_tunnel_key]
[ 261.152392] tcf_action_cleanup+0x2c/0xc0
[ 261.156490] tcf_generic_walker+0x4c2/0x5c0
[ 261.160794] ? tcf_action_dump_1+0x390/0x390
[ 261.165163] ? tunnel_key_walker+0x5/0x1a0 [act_tunnel_key]
[ 261.170865] ? tunnel_key_walker+0xe9/0x1a0 [act_tunnel_key]
[ 261.176641] tca_action_gd+0x600/0xa40
[ 261.180482] ? tca_get_fill.constprop.17+0x200/0x200
[ 261.185548] ? __lock_acquire+0x588/0x1d20
[ 261.189741] ? __lock_acquire+0x588/0x1d20
[ 261.193922] ? mark_held_locks+0x90/0x90
[ 261.197944] ? mark_held_locks+0x90/0x90
[ 261.202018] ? __nla_parse+0xfe/0x190
[ 261.205774] tc_ctl_action+0x218/0x230
[ 261.209614] ? tcf_action_add+0x230/0x230
[ 261.213726] rtnetlink_rcv_msg+0x3a5/0x600
[ 261.217910] ? lock_downgrade+0x2d0/0x2d0
[ 261.222006] ? validate_linkmsg+0x400/0x400
[ 261.226278] ? find_held_lock+0x6d/0xd0
[ 261.230200] ? match_held_lock+0x1b/0x210
[ 261.234296] ? validate_linkmsg+0x400/0x400
[ 261.238567] netlink_rcv_skb+0xc7/0x1f0
[ 261.242489] ? netlink_ack+0x470/0x470
[ 261.246319] ? netlink_deliver_tap+0x1f3/0x5a0
[ 261.250874] netlink_unicast+0x2ae/0x350
[ 261.254884] ? netlink_attachskb+0x340/0x340
[ 261.261647] ? _copy_from_iter_full+0xdd/0x380
[ 261.268576] ? __virt_addr_valid+0xb6/0xf0
[ 261.275227] ? __check_object_size+0x159/0x240
[ 261.282184] netlink_sendmsg+0x4d3/0x630
[ 261.288572] ? netlink_unicast+0x350/0x350
[ 261.295132] ? netlink_unicast+0x350/0x350
[ 261.301608] sock_sendmsg+0x6d/0x80
[ 261.307467] ___sys_sendmsg+0x48e/0x540
[ 261.313633] ? copy_msghdr_from_user+0x210/0x210
[ 261.320545] ? save_stack+0x89/0xb0
[ 261.326289] ? __lock_acquire+0x588/0x1d20
[ 261.332605] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 261.340063] ? mark_held_locks+0x90/0x90
[ 261.346162] ? do_filp_open+0x138/0x1d0
[ 261.352108] ? may_open_dev+0x50/0x50
[ 261.357897] ? match_held_lock+0x1b/0x210
[ 261.364016] ? __fget_light+0xa6/0xe0
[ 261.369840] ? __sys_sendmsg+0xd2/0x150
[ 261.375814] __sys_sendmsg+0xd2/0x150
[ 261.381610] ? __ia32_sys_shutdown+0x30/0x30
[ 261.388026] ? lock_downgrade+0x2d0/0x2d0
[ 261.394182] ? mark_held_locks+0x1c/0x90
[ 261.400230] ? do_syscall_64+0x1e/0x280
[ 261.406172] do_syscall_64+0x78/0x280
[ 261.411932] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 261.419103] RIP: 0033:0x7f28e91a8b87
[ 261.424791] Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00 00 00 00 8b 05 6a 2b 2c 00 48 63 d2 48 63 ff 85 c0 75 18 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 59 f3 c3 0f 1f 80 00 00 00 00 53 48 89 f3 48
[ 261.448226] RSP: 002b:00007ffdc5c4e2d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[ 261.458183] RAX: ffffffffffffffda RBX: 000000005c73c202 RCX: 00007f28e91a8b87
[ 261.467728] RDX: 0000000000000000 RSI: 00007ffdc5c4e340 RDI: 0000000000000003
[ 261.477342] RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000000000c
[ 261.486970] R10: 000000000000000c R11: 0000000000000246 R12: 0000000000000001
[ 261.496599] R13: 000000000067b4e0 R14: 00007ffdc5c5248c R15: 00007ffdc5c52480
[ 261.506281] ==================================================================
[ 261.516076] Disabling lock debugging due to kernel taint
[ 261.523979] BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0
[ 261.534413] #PF error: [normal kernel read fault]
[ 261.541730] PGD 8000000317400067 P4D 8000000317400067 PUD 316878067 PMD 0
[ 261.551294] Oops: 0000 [#1] SMP KASAN PTI
[ 261.557985] CPU: 14 PID: 2976 Comm: tc Tainted: G B 5.0.0-rc7+ #157
[ 261.568306] Hardware name: Supermicro SYS-2028TP-DECR/X10DRT-P, BIOS 2.0b 03/30/2017
[ 261.578874] RIP: 0010:dst_cache_destroy+0x21/0xa0
[ 261.586413] Code: f4 ff ff ff eb f6 0f 1f 00 0f 1f 44 00 00 41 56 41 55 49 c7 c6 60 fe 35 af 41 54 55 49 89 fc 53 bd ff ff ff ff e8 ef 98 73 ff <49> 83 3c 24 00 75 35 eb 6c 4c 63 ed e8 de 98 73 ff 4a 8d 3c ed 40
[ 261.611247] RSP: 0018:ffff888316447160 EFLAGS: 00010282
[ 261.619564] RAX: 0000000000000000 RBX: ffff88835b3e2f00 RCX: ffffffffad1c5071
[ 261.629862] RDX: 0000000000000003 RSI: dffffc0000000000 RDI: 0000000000000297
[ 261.640149] RBP: 00000000ffffffff R08: fffffbfff5dd4e89 R09: fffffbfff5dd4e89
[ 261.650467] R10: 0000000000000001 R11: fffffbfff5dd4e88 R12: 00000000000000b0
[ 261.660785] R13: ffff8883267a10c0 R14: ffffffffaf35fe60 R15: 0000000000000001
[ 261.671110] FS: 00007f28ea3e6400(0000) GS:ffff888364200000(0000) knlGS:0000000000000000
[ 261.682447] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 261.691491] CR2: 00000000000000b0 CR3: 00000003178ae004 CR4: 00000000001606e0
[ 261.701283] Call Trace:
[ 261.706374] tunnel_key_release+0x3a/0x50 [act_tunnel_key]
[ 261.714522] tcf_action_cleanup+0x2c/0xc0
[ 261.721208] tcf_generic_walker+0x4c2/0x5c0
[ 261.728074] ? tcf_action_dump_1+0x390/0x390
[ 261.734996] ? tunnel_key_walker+0x5/0x1a0 [act_tunnel_key]
[ 261.743247] ? tunnel_key_walker+0xe9/0x1a0 [act_tunnel_key]
[ 261.751557] tca_action_gd+0x600/0xa40
[ 261.757991] ? tca_get_fill.constprop.17+0x200/0x200
[ 261.765644] ? __lock_acquire+0x588/0x1d20
[ 261.772461] ? __lock_acquire+0x588/0x1d20
[ 261.779266] ? mark_held_locks+0x90/0x90
[ 261.785880] ? mark_held_locks+0x90/0x90
[ 261.792470] ? __nla_parse+0xfe/0x190
[ 261.798738] tc_ctl_action+0x218/0x230
[ 261.805145] ? tcf_action_add+0x230/0x230
[ 261.811760] rtnetlink_rcv_msg+0x3a5/0x600
[ 261.818564] ? lock_downgrade+0x2d0/0x2d0
[ 261.825433] ? validate_linkmsg+0x400/0x400
[ 261.832256] ? find_held_lock+0x6d/0xd0
[ 261.838624] ? match_held_lock+0x1b/0x210
[ 261.845142] ? validate_linkmsg+0x400/0x400
[ 261.851729] netlink_rcv_skb+0xc7/0x1f0
[ 261.857976] ? netlink_ack+0x470/0x470
[ 261.864132] ? netlink_deliver_tap+0x1f3/0x5a0
[ 261.870969] netlink_unicast+0x2ae/0x350
[ 261.877294] ? netlink_attachskb+0x340/0x340
[ 261.883962] ? _copy_from_iter_full+0xdd/0x380
[ 261.890750] ? __virt_addr_valid+0xb6/0xf0
[ 261.897188] ? __check_object_size+0x159/0x240
[ 261.903928] netlink_sendmsg+0x4d3/0x630
[ 261.910112] ? netlink_unicast+0x350/0x350
[ 261.916410] ? netlink_unicast+0x350/0x350
[ 261.922656] sock_sendmsg+0x6d/0x80
[ 261.928257] ___sys_sendmsg+0x48e/0x540
[ 261.934183] ? copy_msghdr_from_user+0x210/0x210
[ 261.940865] ? save_stack+0x89/0xb0
[ 261.946355] ? __lock_acquire+0x588/0x1d20
[ 261.952358] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 261.959468] ? mark_held_locks+0x90/0x90
[ 261.965248] ? do_filp_open+0x138/0x1d0
[ 261.970910] ? may_open_dev+0x50/0x50
[ 261.976386] ? match_held_lock+0x1b/0x210
[ 261.982210] ? __fget_light+0xa6/0xe0
[ 261.987648] ? __sys_sendmsg+0xd2/0x150
[ 261.993263] __sys_sendmsg+0xd2/0x150
[ 261.998613] ? __ia32_sys_shutdown+0x30/0x30
[ 262.004555] ? lock_downgrade+0x2d0/0x2d0
[ 262.010236] ? mark_held_locks+0x1c/0x90
[ 262.015758] ? do_syscall_64+0x1e/0x280
[ 262.021234] do_syscall_64+0x78/0x280
[ 262.026500] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 262.033207] RIP: 0033:0x7f28e91a8b87
[ 262.038421] Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00 00 00 00 8b 05 6a 2b 2c 00 48 63 d2 48 63 ff 85 c0 75 18 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 59 f3 c3 0f 1f 80 00 00 00 00 53 48 89 f3 48
[ 262.060708] RSP: 002b:00007ffdc5c4e2d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[ 262.070112] RAX: ffffffffffffffda RBX: 000000005c73c202 RCX: 00007f28e91a8b87
[ 262.079087] RDX: 0000000000000000 RSI: 00007ffdc5c4e340 RDI: 0000000000000003
[ 262.088122] RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000000000c
[ 262.097157] R10: 000000000000000c R11: 0000000000000246 R12: 0000000000000001
[ 262.106207] R13: 000000000067b4e0 R14: 00007ffdc5c5248c R15: 00007ffdc5c52480
[ 262.115271] Modules linked in: act_tunnel_key act_skbmod act_simple act_connmark nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 act_csum libcrc32c act_meta_skbtcindex act_meta_skbprio act_meta_mark act_ife ife act_police act_sample psample act_gact veth nfsv3 nfs_acl nfs lockd grace fscache bridge stp llc intel_rapl sb_edac mlx5_ib x86_pkg_temp_thermal sunrpc intel_powerclamp coretemp ib_uverbs kvm_intel ib_core kvm irqbypass mlx5_core crct10dif_pclmul crc32_pclmul crc32c_intel igb ghash_clmulni_intel intel_cstate mlxfw iTCO_wdt devlink intel_uncore iTCO_vendor_support ipmi_ssif ptp mei_me intel_rapl_perf ioatdma joydev pps_core ses mei i2c_i801 pcspkr enclosure lpc_ich dca wmi ipmi_si ipmi_devintf ipmi_msghandler acpi_pad acpi_power_meter pcc_cpufreq ast i2c_algo_bit drm_kms_helper ttm drm mpt3sas raid_class scsi_transport_sas
[ 262.204393] CR2: 00000000000000b0
[ 262.210390] ---[ end trace 2e41d786f2c7901a ]---
[ 262.226790] RIP: 0010:dst_cache_destroy+0x21/0xa0
[ 262.234083] Code: f4 ff ff ff eb f6 0f 1f 00 0f 1f 44 00 00 41 56 41 55 49 c7 c6 60 fe 35 af 41 54 55 49 89 fc 53 bd ff ff ff ff e8 ef 98 73 ff <49> 83 3c 24 00 75 35 eb 6c 4c 63 ed e8 de 98 73 ff 4a 8d 3c ed 40
[ 262.258311] RSP: 0018:ffff888316447160 EFLAGS: 00010282
[ 262.266304] RAX: 0000000000000000 RBX: ffff88835b3e2f00 RCX: ffffffffad1c5071
[ 262.276251] RDX: 0000000000000003 RSI: dffffc0000000000 RDI: 0000000000000297
[ 262.286208] RBP: 00000000ffffffff R08: fffffbfff5dd4e89 R09: fffffbfff5dd4e89
[ 262.296183] R10: 0000000000000001 R11: fffffbfff5dd4e88 R12: 00000000000000b0
[ 262.306157] R13: ffff8883267a10c0 R14: ffffffffaf35fe60 R15: 0000000000000001
[ 262.316139] FS: 00007f28ea3e6400(0000) GS:ffff888364200000(0000) knlGS:0000000000000000
[ 262.327146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 262.335815] CR2: 00000000000000b0 CR3: 00000003178ae004 CR4: 00000000001606e0
Fixes: ee28bb56ac5b ("net/sched: fix memory leak in act_tunnel_key_init()")
Fixes: 41411e2fd6b8 ("net/sched: act_tunnel_key: Add dst_cache support")
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
---
net/sched/act_tunnel_key.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/net/sched/act_tunnel_key.c b/net/sched/act_tunnel_key.c
index 3404af72b4c1..2a5f215ae876 100644
--- a/net/sched/act_tunnel_key.c
+++ b/net/sched/act_tunnel_key.c
@@ -201,8 +201,14 @@ static void tunnel_key_release_params(struct tcf_tunnel_key_params *p)
{
if (!p)
return;
- if (p->tcft_action == TCA_TUNNEL_KEY_ACT_SET)
+ if (p->tcft_action == TCA_TUNNEL_KEY_ACT_SET) {
+#ifdef CONFIG_DST_CACHE
+ struct ip_tunnel_info *info = &p->tcft_enc_metadata->u.tun_info;
+
+ dst_cache_destroy(&info->dst_cache);
+#endif
dst_release(&p->tcft_enc_metadata->dst);
+ }
kfree_rcu(p, rcu);
}
@@ -384,10 +390,12 @@ static int tunnel_key_init(struct net *net, struct nlattr *nla,
release_dst_cache:
#ifdef CONFIG_DST_CACHE
- dst_cache_destroy(&metadata->u.tun_info.dst_cache);
+ if (metadata)
+ dst_cache_destroy(&metadata->u.tun_info.dst_cache);
#endif
release_tun_meta:
- dst_release(&metadata->dst);
+ if (metadata)
+ dst_release(&metadata->dst);
err_out:
if (exists)
@@ -401,15 +409,8 @@ static void tunnel_key_release(struct tc_action *a)
{
struct tcf_tunnel_key *t = to_tunnel_key(a);
struct tcf_tunnel_key_params *params;
-#ifdef CONFIG_DST_CACHE
- struct ip_tunnel_info *info;
-#endif
params = rcu_dereference_protected(t->params, 1);
-#ifdef CONFIG_DST_CACHE
- info = ¶ms->tcft_enc_metadata->u.tun_info;
- dst_cache_destroy(&info->dst_cache);
-#endif
tunnel_key_release_params(params);
}
--
2.13.6
^ permalink raw reply related
* [PATCH] cfg80211: Use kmemdup in cfg80211_gen_new_ie()
From: YueHaibing @ 2019-02-25 12:38 UTC (permalink / raw)
To: Johannes Berg; +Cc: YueHaibing, linux-wireless, netdev, kernel-janitors
Use kmemdup rather than duplicating its implementation
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
net/wireless/scan.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 287518c6caa4..04d888628f29 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -190,10 +190,9 @@ static size_t cfg80211_gen_new_ie(const u8 *ie, size_t ielen,
/* copy subelement as we need to change its content to
* mark an ie after it is processed.
*/
- sub_copy = kmalloc(subie_len, gfp);
+ sub_copy = kmemdup(subelement, subie_len, gfp);
if (!sub_copy)
return 0;
- memcpy(sub_copy, subelement, subie_len);
pos = &new_ie[0];
^ permalink raw reply related
* Re: [PATCH net v2 2/2] selftests: pmtu: add explicit tests for PMTU exceptions cleanup
From: Sabrina Dubroca @ 2019-02-25 12:33 UTC (permalink / raw)
To: Paolo Abeni; +Cc: netdev, David S. Miller, David Ahern, Stefano Brivio
In-Reply-To: <6d6f6a2512743d6e1968dbfe765eb85b478bd033.1551093086.git.pabeni@redhat.com>
2019-02-25, 12:13:46 +0100, Paolo Abeni wrote:
> + if ! timeout 1 ${ns_a} ip link del dev veth_A-R1; then
That doesn't work. "ip link del" is stuck in a way that timeout can't
terminate it, so this is still going to hang. Did you actually test
this? :/
> + err " can't delete veth device in a timely manner, PMTU dst likely leaked"
> + return 1
> + fi
> + return 0
> +}
--
Sabrina
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: Add support for 200Gbps (50Gbps per lane) link mode
From: Aya Levin @ 2019-02-25 12:42 UTC (permalink / raw)
To: Michal Kubecek, Andrew Lunn
Cc: Tariq Toukan, John W. Linville, netdev@vger.kernel.org,
Eran Ben Elisha
In-Reply-To: <20190224184046.GB1914@unicorn.suse.cz>
On 2/24/2019 8:40 PM, Michal Kubecek wrote:
> On Sun, Feb 24, 2019 at 05:47:51PM +0100, Andrew Lunn wrote:
>> On Sun, Feb 24, 2019 at 05:08:21PM +0200, Tariq Toukan wrote:
>>> From: Aya Levin <ayal@mellanox.com>
>>> index 5a26cff5fb33..64ce0711ad5f 100644
>>> --- a/ethtool.8.in
>>> +++ b/ethtool.8.in
>>> @@ -650,6 +650,11 @@ lB l lB.
>>> 0x400000000 50000baseCR2 Full
>>> 0x800000000 50000baseKR2 Full
>>> 0x10000000000 50000baseSR2 Full
>>> +0x10000000000000 50000baseKR Full
>>> +0x20000000000000 50000baseSR Full
>>> +0x40000000000000 50000baseCR Full
>>> +0x80000000000000 50000baseLR_ER_FR Full
>>> +0x100000000000000 50000baseDR Full
>>> 0x8000000 56000baseKR4 Full
>>> 0x10000000 56000baseCR4 Full
>>> 0x20000000 56000baseSR4 Full
>>> @@ -658,6 +663,16 @@ lB l lB.
>>> 0x2000000000 100000baseSR4 Full
>>> 0x4000000000 100000baseCR4 Full
>>> 0x8000000000 100000baseLR4_ER4 Full
>>> +0x200000000000000 100000baseKR2 Full
>>> +0x400000000000000 100000baseSR2 Full
>>> +0x800000000000000 100000baseCR2 Full
>>> +0x1000000000000000 100000baseLR2_ER2_FR2 Full
>>> +0x2000000000000000 100000baseDR2 Full
>>> +0x4000000000000000 200000baseKR4 Full
>>> +0x8000000000000000 200000baseSR4 Full
>>> +0x10000000000000000 200000baseLR4_ER4_FR4 Full
>>> +0x20000000000000000 200000baseDR4 Full
>>> +0x40000000000000000 200000baseCR4 Full
>>
>> This is getting less friendly all the time, and it was never very
>> friendly to start with. We have the strings which represent these link
>> modes in the table used for dumping caps. How about allowing the user
>> to list a comma separate list of modes.
>>
>> ethtool -s lan42 advertise 100000baseKR2/Full,100000baseSR2/Full,100000baseCR2/Full
>
> In my preliminary netlink patchset, I'm adding support for e.g.
>
> ethtool -s eth0 advertise 100baseT/Half off 1000baseT/Full on
>
> I'm not sure what would be more useful, if switching individual modes or
> listing the whole set. After all, we can also support both. But I fully
> agree that the numeric bitmaps are already too inconvenient.
>
>>> + adv_bit = ETHTOOL_LINK_MODE_200000baseKR4_Full_BIT &
>>> + ETHTOOL_LINK_MODE_200000baseSR4_Full_BIT &
>>> + ETHTOOL_LINK_MODE_200000baseLR4_ER4_FR4_Full_BIT &
>>> + ETHTOOL_LINK_MODE_200000baseDR4_Full_BIT &
>>> + ETHTOOL_LINK_MODE_200000baseCR4_Full_BIT;
>>
>> Maybe i'm wrong, but this looks odd.
>>
>> enum ethtool_link_mode_bit_indices {
>> ETHTOOL_LINK_MODE_10baseT_Half_BIT = 0,
>> ETHTOOL_LINK_MODE_10baseT_Full_BIT = 1,
>> ETHTOOL_LINK_MODE_100baseT_Half_BIT = 2,
>> ETHTOOL_LINK_MODE_100baseT_Full_BIT = 3,
>> ETHTOOL_LINK_MODE_1000baseT_Half_BIT = 4,
>> ETHTOOL_LINK_MODE_1000baseT_Full_BIT = 5,
>>
>> These are numbers, not bitmasks, so & them together does not look
>> correct.
>
> Yes, this is wrong. Even if bit masks were used, the operator should be
> "|" but here adv_bit is interpreted as an index, not mask. It's obvious
> this part of the code was designed when speed and duplex identified the
> mode uniquely which is no longer the case. (Which is probably also why
> there are no branches for speeds over 10G.)
>
> And there is another problem:
>
> + else if (speed_wanted == SPEED_20000 &&
> + duplex_wanted == DUPLEX_FULL)
> + adv_bit = ETHTOOL_LINK_MODE_200000baseKR4_Full_BIT &
> + ETHTOOL_LINK_MODE_200000baseSR4_Full_BIT &
> + ETHTOOL_LINK_MODE_200000baseLR4_ER4_FR4_Full_BIT &
> + ETHTOOL_LINK_MODE_200000baseDR4_Full_BIT &
> + ETHTOOL_LINK_MODE_200000baseCR4_Full_BIT;
>
> The test is for SPEED_20000 but then 200G modes are added.
>
> Michal
>
Thanks Michal and Andrew for your comments - I will fix them in the next
version.
The code section (setting advertisement of 200G) will be removed
completely, advertisement of 200G will be set to the supported
link-modes that is handled below.
In addition I will make sure ethtool-copy.h is synced with current
kernel version without additions.
As for the man page, I agree with you completely - I thought of
replacing the LONG hex values with BIT(x) but since this can not be
applied in the command line - I didn't implement it.
Aya
^ permalink raw reply
* Re: [PATCH 0/4] mwifiex PCI/wake-up interrupt fixes
From: Ard Biesheuvel @ 2019-02-25 12:45 UTC (permalink / raw)
To: Marc Zyngier
Cc: Amitkumar Karwar, Enric Balletbo i Serra, Ganapathi Bhat,
Heiko Stuebner, Kalle Valo, Nishant Sarmukadam, Rob Herring,
Xinming Hu, Devicetree List, <netdev@vger.kernel.org>,
<linux-wireless@vger.kernel.org>, Linux Kernel Mailing List,
linux-rockchip, David S. Miller, linux-arm-kernel
In-Reply-To: <20190224140426.3267-1-marc.zyngier@arm.com>
On Sun, 24 Feb 2019 at 15:08, Marc Zyngier <marc.zyngier@arm.com> wrote:
>
> For quite some time, I wondered why the PCI mwifiex device built in my
> Chromebook was unable to use the good old legacy interrupts. But as MSIs
> were working fine, I never really bothered investigating. I finally had a
> look, and the result isn't very pretty.
>
> On this machine (rk3399-based kevin), the wake-up interrupt is described as
> such:
>
> &pci_rootport {
> mvl_wifi: wifi@0,0 {
> compatible = "pci1b4b,2b42";
> reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
> 0x83010000 0x0 0x00100000 0x0 0x00100000>;
> interrupt-parent = <&gpio0>;
> interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> pinctrl-names = "default";
> pinctrl-0 = <&wlan_host_wake_l>;
> wakeup-source;
> };
> };
>
> Note how the interrupt is part of the properties directly attached to the
> PCI node. And yet, this interrupt has nothing to do with a PCI legacy
> interrupt, as it is attached to the wake-up widget that bypasses the PCIe RC
> altogether (Yay for the broken design!). This is in total violation of the
> IEEE Std 1275-1994 spec[1], which clearly documents that such interrupt
> specifiers describe the PCI device interrupts, and must obey the
> INT-{A,B,C,D} mapping. Oops!
>
The mapping of legacy PCIe INTx interrupts onto wired system
interrupts is a property of the PCIe host controller, not of a
particular PCIe device. So I would argue that the code is broken here
as well: it should never attempt to interpret 'interrupt' properties
at the PCI device level as having any bearing on how legacy interrupts
are routed.
> The net effect of the above is that Linux tries to do something vaguely
> sensible, and uses the same interrupt for both the wake-up widget and the
> PCI device. This doesn't work for two reasons: (1) the wake-up widget grabs
> the interrupt in exclusive mode, and (2) the PCI interrupt is still routed
> to the RC, leading to a screaming interrupt. This simply cannot work.
>
> To sort out this mess, we need to lift the confusion between the two
> interrupts. This is done by extending the DT binding to allow the wake-up
> interrupt to be described in a 'wake-up' subnode, sidestepping the issue
> completely. On my Chromebook, it now looks like this:
>
> &pci_rootport {
> mvl_wifi: wifi@0,0 {
> compatible = "pci1b4b,2b42";
> reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
> 0x83010000 0x0 0x00100000 0x0 0x00100000>;
> pinctrl-names = "default";
> pinctrl-0 = <&wlan_host_wake_l>;
> wake-up {
> interrupt-parent = <&gpio0>;
> interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
> wakeup-source;
> };
> };
> };
>
> The driver is then updated to look for this subnode first, and fallback to
> the original, broken behaviour (spitting out a warning in the offending
> configuration).
>
> For good measure, there are two additional patches:
>
> - The wake-up interrupt requesting is horribly racy, and could lead to
> unpredictable behaviours. Let's fix that properly.
>
> - A final patch implementing the above transformation for the whole
> RK3399-based Chromebook range, which all use the same broken
> configuration.
>
> With all that, I finally have PCI legacy interrupts working with the mwifiex
> driver on my Chromebook.
>
> [1] http://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf
>
> Marc Zyngier (4):
> dt-bindings/marvell-8xxx: Allow wake-up interrupt to be placed in a
> separate node
> mwifiex: Fetch wake-up interrupt from 'wake-up' subnode when it exists
> mwifiex: Flag wake-up interrupt as IRQ_NOAUTOEN rather than disabling
> it too late
> arm64: dts: rockchip: gru: Move wifi wake-up interrupt into its own
> subnode
>
> .../bindings/net/wireless/marvell-8xxx.txt | 23 ++++++++++++++++++-
> .../dts/rockchip/rk3399-gru-chromebook.dtsi | 8 ++++---
> drivers/net/wireless/marvell/mwifiex/main.c | 13 +++++++++--
> 3 files changed, 38 insertions(+), 6 deletions(-)
>
> --
> 2.20.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net] sctp: get sctphdr by offset in sctp_compute_cksum
From: Neil Horman @ 2019-02-25 12:46 UTC (permalink / raw)
To: Xin Long
Cc: linux-kernel, network dev, linux-sctp, davem,
Marcelo Ricardo Leitner
In-Reply-To: <2aee76766861ac9e46b7acf123d5d6e8f2adf8e0.1551093937.git.lucien.xin@gmail.com>
On Mon, Feb 25, 2019 at 07:25:37PM +0800, Xin Long wrote:
> sctp_hdr(skb) only works when skb->transport_header is set properly.
>
> But in the path of nf_conntrack_in: sctp_packet() -> sctp_error()
>
> skb->transport_header is not guaranteed to be right value for sctp.
> It will cause to fail to check the checksum for sctp packets.
>
> So fix it by using offset, which is always right in all places.
>
> Fixes: e6d8b64b34aa ("net: sctp: fix and consolidate SCTP checksumming code")
> Reported-by: Li Shuang <shuali@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> include/net/sctp/checksum.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/net/sctp/checksum.h b/include/net/sctp/checksum.h
> index 32ee65a..1c6e6c0 100644
> --- a/include/net/sctp/checksum.h
> +++ b/include/net/sctp/checksum.h
> @@ -61,7 +61,7 @@ static inline __wsum sctp_csum_combine(__wsum csum, __wsum csum2,
> static inline __le32 sctp_compute_cksum(const struct sk_buff *skb,
> unsigned int offset)
> {
> - struct sctphdr *sh = sctp_hdr(skb);
> + struct sctphdr *sh = (struct sctphdr *)(skb->data + offset);
> const struct skb_checksum_ops ops = {
> .update = sctp_csum_update,
> .combine = sctp_csum_combine,
> --
> 2.1.0
>
>
Shouldn't you use skb_set_transport_header and skb_transport_header here?
Neil
^ permalink raw reply
* Re: [PATCH net v2 2/2] selftests: pmtu: add explicit tests for PMTU exceptions cleanup
From: Stefano Brivio @ 2019-02-25 12:56 UTC (permalink / raw)
To: Sabrina Dubroca, Paolo Abeni; +Cc: netdev, David S. Miller, David Ahern
In-Reply-To: <20190225123330.GA10994@bistromath.localdomain>
On Mon, 25 Feb 2019 13:33:30 +0100
Sabrina Dubroca <sd@queasysnail.net> wrote:
> 2019-02-25, 12:13:46 +0100, Paolo Abeni wrote:
> > + if ! timeout 1 ${ns_a} ip link del dev veth_A-R1; then
>
> That doesn't work. "ip link del" is stuck in a way that timeout can't
> terminate it, so this is still going to hang. Did you actually test
> this? :/
Indeed, upon actual testing, this hangs and the error is not reported.
> > + err " can't delete veth device in a timely
> > manner, PMTU dst likely leaked"
> > + return 1
> > + fi
> > + return 0
> > +}
You can use a subshell here, something like:
${ns_a} ip link del dev veth_A-R1 &
iplink_pid=$!
sleep 1
if [ "$(cat /proc/${iplink_pid}/cmdline 2>/dev/null | tr -d '\0')" = "iplinkdeldevveth_A-R1" ]; then
err " can't delete veth device in a timely manner, PMTU dst likely leaked"
return 1
fi
}
and now that I tried to run as a single test and couldn't find it, I
think it would also be worth it to rename the tests to something more
sensible.
Right now you have test_pmtu_ipv6_exception_cleanup() calling
test_cleanup_...(), I think it's confusing. Just call the test
test_cleanup_ipv6_exception(), it doesn't have so much to do with PMTU
anyway.
--
Stefano
^ permalink raw reply
* Re: [PATCH] net: dsa: Inherit dev addr from master
From: xiaofeis @ 2019-02-25 13:13 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vinod Koul, David S. Miller, linux-arm-msm, Bjorn Andersson,
Vivien Didelot, Florian Fainelli, Niklas Cassel, netdev
In-Reply-To: <20190222143003.GL5653@lunn.ch>
On 2019-02-22 22:30, Andrew Lunn wrote:
> On Fri, Feb 22, 2019 at 06:26:54PM +0530, Vinod Koul wrote:
>> From: Xiaofei Shen <xiaofeis@codeaurora.org>
>>
>> When we create slave netdevice, the dev addr is inherited from master
>> but the master dev addr maybe NULL at that time, so inherit it again
>> while opening the slave.
>
> Hi Xiaofei, Vinod
>
> Inheriting it twice seems a bit clumsy. Can the first inherit be
> removed? Can you change your MAC driver to set its MAC address in
> probe?
>
> Andrew
Hi Andrew
Some mac driver set its MAC address in probe while some MAC driver do it
in the open function in the kernel.
This patch is checking whether the address is valid firstly, if it
already inherits a valid mac address, it will not inherit again.
I think we can remove the first inherit, but if keep it, we can see
consistent address output by ifconfig -a before open master and slave
interface.
Xiaofeis
^ permalink raw reply
* Re: [PATCH net] sctp: get sctphdr by offset in sctp_compute_cksum
From: Xin Long @ 2019-02-25 13:20 UTC (permalink / raw)
To: Neil Horman; +Cc: LKML, network dev, linux-sctp, davem, Marcelo Ricardo Leitner
In-Reply-To: <20190225124614.GB30699@hmswarspite.think-freely.org>
On Mon, Feb 25, 2019 at 8:47 PM Neil Horman <nhorman@tuxdriver.com> wrote:
>
> On Mon, Feb 25, 2019 at 07:25:37PM +0800, Xin Long wrote:
> > sctp_hdr(skb) only works when skb->transport_header is set properly.
> >
> > But in the path of nf_conntrack_in: sctp_packet() -> sctp_error()
> >
> > skb->transport_header is not guaranteed to be right value for sctp.
> > It will cause to fail to check the checksum for sctp packets.
> >
> > So fix it by using offset, which is always right in all places.
> >
> > Fixes: e6d8b64b34aa ("net: sctp: fix and consolidate SCTP checksumming code")
> > Reported-by: Li Shuang <shuali@redhat.com>
> > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > ---
> > include/net/sctp/checksum.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/net/sctp/checksum.h b/include/net/sctp/checksum.h
> > index 32ee65a..1c6e6c0 100644
> > --- a/include/net/sctp/checksum.h
> > +++ b/include/net/sctp/checksum.h
> > @@ -61,7 +61,7 @@ static inline __wsum sctp_csum_combine(__wsum csum, __wsum csum2,
> > static inline __le32 sctp_compute_cksum(const struct sk_buff *skb,
> > unsigned int offset)
> > {
> > - struct sctphdr *sh = sctp_hdr(skb);
> > + struct sctphdr *sh = (struct sctphdr *)(skb->data + offset);
> > const struct skb_checksum_ops ops = {
> > .update = sctp_csum_update,
> > .combine = sctp_csum_combine,
> > --
> > 2.1.0
> >
> >
> Shouldn't you use skb_set_transport_header and skb_transport_header here?
you mean:
skb_set_transport_header(skb, offset);
sh = sctp_hdr(skb);
?
There's no place counting on here to set transport_header.
It will be a kinda redundant job, yet skb is 'const'.
^ permalink raw reply
* Re: [PATCH] net: dsa: Inherit dev addr from master
From: Andrew Lunn @ 2019-02-25 13:21 UTC (permalink / raw)
To: xiaofeis
Cc: Vinod Koul, David S. Miller, linux-arm-msm, Bjorn Andersson,
Vivien Didelot, Florian Fainelli, Niklas Cassel, netdev
In-Reply-To: <441ae81a814498876e4cfed6fd5b7bcb@codeaurora.org>
> I think we can remove the first inherit, but if keep it, we can see
> consistent address output by ifconfig -a before open master and slave
> interface.
True
But it also means we see inconsistent MAC addresses on the master. The
MAC address changes on open.
Maybe it would be better to change your master so it sets its MAC
address during probe? Everything is then consistent all the time.
Andrew
^ permalink raw reply
* Re: [PATCH] net: dsa: read mac address from DT for slave device
From: xiaofeis @ 2019-02-25 13:28 UTC (permalink / raw)
To: Florian Fainelli
Cc: Vinod Koul, David S. Miller, linux-arm-msm, Bjorn Andersson,
Andrew Lunn, Vivien Didelot, Niklas Cassel, netdev
In-Reply-To: <9baf097f-37ea-2bef-92dd-25a7040a16ed@gmail.com>
Hi Florian
We have two slave DSA interfaces, wan0 and lan0, one is for wan port,
and the other is for lan port. Customer has it's mac address pool, they
want
to assign the mac address from the pool on wan0, lan0, and other
interfaces like
wifi, bt. Coreboot/uboot will populate it to the DTS node, so the driver
can
get it from it's node. For DSA slave interface, it already has it's own
DTS node, it's
easy to just add one porperty "local-mac-address" there for the usage in
DSA driver.
If not use DSA framework, normally we will use eth0.x and eth0.y for wan
and lan.
On this case, customer usually also assign the MAC address on these
logical interface
from it's pool.
On 2019-02-22 23:43, Florian Fainelli wrote:
> On 2/22/19 4:58 AM, Vinod Koul wrote:
>> From: Xiaofei Shen <xiaofeis@codeaurora.org>
>>
>> Before creating a slave netdevice, get the mac address from DTS and
>> apply in case it is valid.
>
> Can you explain your use case in details?
>
> Assigning a MAC address to a network device that represents a switch
> port does not quite make sense in general. The switch port is really
> representing one end of a pipe, so one side you have stations and on
> the
> other side, you have the CPU/management Ethernet MAC controller's MAC
> address which constitutes a station as well. The DSA slave network
> devices are just software constructs meant to steer traffic towards
> specific ports of the switch, but they are all from the perpsective of
> traffic reaching the CPU Port in the first place, therefore traffic
> that
> is generally a known unicast Ethernet frame with the CPU's MAC address
> as MAC DA (and of course all types of unknown MC, management traffic
> etc.)
>
> By default, DSA switch need to come up in a configuration where all
> ports (except CPU/management) must be strictly separate from every
> other
> port such that we can achieve what a standalone Ethernet NIC would do.
> This works because all ports are isolated from one another, so there is
> no cross talk and so having the same MAC address (the one from the CPU)
> on the DSA slave network devices just works, each port is a separate
> broadcast domain.
>
> Once you start bridging one or ore ports, the bridge root port will
> have
> a MAC address, most likely the one the CPU/management Ethernet MAC, but
> similarly, this is not an issue and that's exactly how a software
> bridge
> would work as well.
>
>>
>> Signed-off-by: Xiaofei Shen <xiaofeis@codeaurora.org>
>> Signed-off-by: Vinod Koul <vkoul@kernel.org>
>> ---
>> include/net/dsa.h | 1 +
>> net/dsa/dsa2.c | 1 +
>> net/dsa/slave.c | 5 ++++-
>> 3 files changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/net/dsa.h b/include/net/dsa.h
>> index b3eefe8e18fd..aa24ce756679 100644
>> --- a/include/net/dsa.h
>> +++ b/include/net/dsa.h
>> @@ -198,6 +198,7 @@ struct dsa_port {
>> unsigned int index;
>> const char *name;
>> const struct dsa_port *cpu_dp;
>> + const char *mac;
>> struct device_node *dn;
>> unsigned int ageing_time;
>> u8 stp_state;
>> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
>> index a1917025e155..afb7d9fa42f6 100644
>> --- a/net/dsa/dsa2.c
>> +++ b/net/dsa/dsa2.c
>> @@ -261,6 +261,7 @@ static int dsa_port_setup(struct dsa_port *dp)
>> int err = 0;
>>
>> memset(&dp->devlink_port, 0, sizeof(dp->devlink_port));
>> + dp->mac = of_get_mac_address(dp->dn);
>>
>> if (dp->type != DSA_PORT_TYPE_UNUSED)
>> err = devlink_port_register(ds->devlink, &dp->devlink_port,
>> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
>> index a3fcc1d01615..8e64c4e947c6 100644
>> --- a/net/dsa/slave.c
>> +++ b/net/dsa/slave.c
>> @@ -1308,7 +1308,10 @@ int dsa_slave_create(struct dsa_port *port)
>> slave_dev->features = master->vlan_features | NETIF_F_HW_TC;
>> slave_dev->hw_features |= NETIF_F_HW_TC;
>> slave_dev->ethtool_ops = &dsa_slave_ethtool_ops;
>> - eth_hw_addr_inherit(slave_dev, master);
>> + if (port->mac && is_valid_ether_addr(port->mac))
>> + ether_addr_copy(slave_dev->dev_addr, port->mac);
>> + else
>> + eth_hw_addr_inherit(slave_dev, master);
>> slave_dev->priv_flags |= IFF_NO_QUEUE;
>> slave_dev->netdev_ops = &dsa_slave_netdev_ops;
>> slave_dev->switchdev_ops = &dsa_slave_switchdev_ops;
>>
^ 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