From: Simon Horman <horms@kernel.org>
To: Xiaoliang Yang <xiaoliang.yang_1@nxp.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
jhs@mojatatu.com, jiri@resnulli.us, shuah@kernel.org,
vladimir.oltean@nxp.com, vinicius.gomes@intel.com,
fejes@inf.elte.hu
Subject: Re: [PATCH net-next 6/6] selftests: net: add kselftest for IEEE 802.1CB FRER tc action
Date: Fri, 24 Jul 2026 13:48:01 +0100 [thread overview]
Message-ID: <20260724124801.GJ418547@horms.kernel.org> (raw)
In-Reply-To: <20260717095549.10565-7-xiaoliang.yang_1@nxp.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev/#/patchset/20260717095549.10565-3-xiaoliang.yang_1@nxp.com?part=6
---
--- Patch [6]: [PATCH net-next 6/6] selftests: net: add kselftest for IEEE 802.1CB FRER tc action ---
commit af0b752d09a70dfd74c1c5880e3ee38044b284c6
Author: Xiaoliang Yang <xiaoliang.yang_1@nxp.com>
selftests: net: add kselftest for IEEE 802.1CB FRER tc action
Add a TAP-format kselftest script covering the FRER tc action. The tests
exercise shared and individual recover modes using bond, point-to-point,
and relay topologies.
> diff --git a/tools/testing/selftests/net/frer_test.sh b/tools/testing/selftests/net/frer_test.sh
> new file mode 100755
> index 0000000000000..ecd88952f4958
> --- /dev/null
> +++ b/tools/testing/selftests/net/frer_test.sh
[ ... ]
> +cleanup()
> +{
> + for n in "$NS_TALKER" "$NS_LISTENER" \
> + "$P2P_NS_SRC" "$P2P_NS_DST" \
> + "$R_NS_TALKER" "$R_NS_BRIDGE0" "$R_NS_BRIDGE1" "$R_NS_LISTENER"; do
> + ip netns del "$n" 2>/dev/null || true
> + done
> +}
> +trap cleanup EXIT
[Severity: Low]
Does this cleanup handler leak temporary packet capture files?
The test allocates files via mktemp /tmp/frer_... earlier, but this trap
handler only removes network namespaces and does not issue an rm for the
pcap files.
[ ... ]
> +capture_start_on()
> +{
[ ... ]
> + # Wait until tcpdump opens a packet socket (max ~2.5 s).
> + local tries=0
> + while [ $tries -lt 50 ]; do
> + ip netns exec "$ns" grep -q "$iface" /proc/net/packet 2>/dev/null && break
Simon says: I believe the common approach for the issue flagged below
is to simply "sleep 1".
Which has the advantage of being simple.
Otherwise the index can be looked up from sysfs:
/sys/class/net/$iface/ifindex
[Severity: Medium]
Will this grep always fail and exhaust the 50-iteration retry limit?
/proc/net/packet exposes the integer ifindex of the interface, not the
string name.
This could cause a 2.5-second block per capture, wasting most of the 4-second
tcpdump timeout window. This leaves only 1.5s for the ping command and could
potentially cause test flakiness.
> + sleep 0.05
> + tries=$((tries + 1))
> + done
> +}
> +
> +capture_stop()
> +{
> + [ -n "$_CAP_PID" ] || return 0
> + wait "$_CAP_PID" 2>/dev/null || true
Simon says: The issue flagged below like a design decision,
I think we can pass on it.
[Severity: Medium]
Could this cause the script to idly block for the remainder of the 4-second
tcpdump timeout?
Because capture_start_on() spawns tcpdump using timeout 4 tcpdump &, running
wait without first sending a termination signal means it waits for the
timeout to expire naturally.
This could add significant delay across the full test suite.
> + _CAP_PID=""
> +}
[ ... ]
> +test_individual_recover_bond()
> +{
[ ... ]
> + # Per-slave capture A: verify veth_a1 passes frames; also use this run
> + # for the overall ping_rc check (do_ping targets bond0->bond1).
> + pcap_a=$(mktemp /tmp/frer_bond_indv_a_XXXXXX.pcap)
> + capture_start_on "$NS_LISTENER" "$VETH_A1" "$pcap_a" "icmp"
Simon says: The issue flagged below seems to be a false-positive.
[Severity: Medium]
Will this BPF filter drop the ingress R-TAG frames?
Since tcpdump opens an AF_PACKET socket, it taps ingress frames in
__netif_receive_skb_core() before sch_handle_ingress() is called.
The ingress frame still contains the FRER R-TAG (EtherType 0xF1C1) and would
bypass the icmp (0x0800) filter, potentially leading to 0 captured ingress
ICMP frames and a deterministic test failure.
> + do_ping || ping_rc=$?
> + capture_stop
[ ... ]
> +main()
> +{
[ ... ]
> + ksft_print_cnts
> +
> + [ "$_ksft_fail" -eq 0 ] && ksft_exit_pass || ksft_exit_fail
[Severity: High]
Can this unconditionally fail the test with a bash syntax error?
When run in the kselftest tree, the script sources kselftest/lib.sh, which
skips the else block that initializes _ksft_fail=0.
Evaluating this with an unset variable triggers an integer expression
expected error and unconditionally takes the ksft_exit_fail path.
> +}
> +
> +main "$@"
next prev parent reply other threads:[~2026-07-24 12:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 9:55 [PATCH net-next 0/6] tc: introduce FRER action (IEEE 802.1CB) Xiaoliang Yang
2026-07-17 9:55 ` [PATCH net-next 1/6] uapi: if_ether: add ETH_P_RTAG for IEEE 802.1CB R-TAG Xiaoliang Yang
2026-07-17 9:55 ` [PATCH net-next 2/6] uapi: pkt_cls: add TCA_ID_FRER action identifier Xiaoliang Yang
2026-07-17 9:55 ` [PATCH net-next 3/6] uapi: tc_act: add tc_frer UAPI header Xiaoliang Yang
2026-07-24 11:49 ` Simon Horman
2026-07-17 9:55 ` [PATCH net-next 4/6] net: sched: act_frer: add FRER tc action Xiaoliang Yang
2026-07-24 12:33 ` Simon Horman
2026-07-17 9:55 ` [PATCH net-next 5/6] selftest: add tc-testing JSON test cases for act_frer Xiaoliang Yang
2026-07-24 12:34 ` Simon Horman
2026-07-17 9:55 ` [PATCH net-next 6/6] selftests: net: add kselftest for IEEE 802.1CB FRER tc action Xiaoliang Yang
2026-07-24 12:48 ` Simon Horman [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-06-22 9:21 [PATCH net-next 0/6] tc: introduce FRER action (IEEE 802.1CB) Xiaoliang Yang
2026-06-22 9:21 ` [PATCH net-next 6/6] selftests: net: add kselftest for IEEE 802.1CB FRER tc action Xiaoliang Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260724124801.GJ418547@horms.kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fejes@inf.elte.hu \
--cc=jhs@mojatatu.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@kernel.org \
--cc=vinicius.gomes@intel.com \
--cc=vladimir.oltean@nxp.com \
--cc=xiaoliang.yang_1@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox