The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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 "$@"

  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