Re: [PATCH v3 net-next 03/15] selftests: xsk: drop the single-interface loopback mode

[Maciej Fijalkowski <maciej.fijalkowski@intel.com>]

On Sat, Oct 17, 2026 at 03:06:05AM +0000, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider.
> 
> Critical: 0 · High: 0 · Medium: 1 · Low: 0
> 
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
> 
> - [Medium] Old single-interface invocations are now misread instead of
>   being rejected.
> 
> --
> 
> selftests: xsk: drop the single-interface loopback mode
> 
> This commit removes the xskxceiver mode where the TX and RX sockets were
> bound to queue 0 of one interface with a shared UMEM. It also removes the
> split UMEM addressing and the POLL_TXQ_FULL workaround that mode needed.
> The -i IFACE option of test_xsk.sh is dropped as well.
> 
> > diff --git a/tools/testing/selftests/bpf/test_xsk.sh b/tools/testing/selftests/bpf/test_xsk.sh
> > index 62db060298a4a..69fac65f073c5 100755
> > --- a/tools/testing/selftests/bpf/test_xsk.sh
> > +++ b/tools/testing/selftests/bpf/test_xsk.sh
> 
> [ ... ]
> 
> > @@ -88,14 +85,11 @@
> >  
> >  . xsk_prereqs.sh
> >  
> > -ETH=""
> > -
> > -while getopts "vi:dm:lt:h" flag
> > +while getopts "vdm:lt:h" flag
> >  do
> >  	case "${flag}" in
> >  		v) verbose=1;;
> >  		d) debug=1;;
> > -		i) ETH=${OPTARG};;
> >  		m) MODE=${OPTARG};;
> >  		l) list=1;;
> >  		t) TEST=${OPTARG};;
> 
> [ ... ]
> 
> > diff --git a/tools/testing/selftests/bpf/xskxceiver.c b/tools/testing/selftests/bpf/xskxceiver.c
> > index 7dad8556a722e..24109dd7264e2 100644
> > --- a/tools/testing/selftests/bpf/xskxceiver.c
> > +++ b/tools/testing/selftests/bpf/xskxceiver.c
> 
> [ ... ]
> 
> > @@ -388,10 +387,6 @@ int main(int argc, char **argv)
> >  		ksft_exit_xfail();
> >  	}
> >  
> > -	shared_netdev = (ifobj_tx->ifindex == ifobj_rx->ifindex);
> > -	ifobj_tx->shared_umem = shared_netdev;
> > -	ifobj_rx->shared_umem = shared_netdev;
> > -
> >  	if (!validate_interface(ifobj_tx) || !validate_interface(ifobj_rx))
> >  		print_usage(argv);
> 
> [Severity: Medium]
> Now that shared_netdev is gone, what rejects the old
> "xskxceiver -i ethX -i ethX" invocation?
> 
> parse_command_line() still sets ifobj_tx and ifobj_rx from the first two
> -i options. validate_interface() only rejects an empty name. As a result,
> TX and RX can use the same ifindex and nothing reports it.
> 
> When that happens, each endpoint binds its own UMEM to queue 0 of the same
> netdev, because xsk_configure() now does:
> 
> 	bool shared = !!i;
> 
> The TX bind cannot succeed without XDP_SHARED_UMEM. xsk_configure()
> retries SOCK_RECONF_CTR times, and then every test fails. Nothing tells
> the user that the mode was removed.
> 
> xsk_attach_xdp_progs() has also lost its early return for a shared-netdev
> TX side, so the TX attach replaces the RX program on the same ifindex.
> 
> Should main() exit with a usage error when
> ifobj_tx->ifindex == ifobj_rx->ifindex?
> 
> test_xsk.sh has a related problem. 'i' is no longer in the getopts string,
> and the case statement has no '?' arm. Running "test_xsk.sh -i ethX"
> prints an illegal option warning and then runs the veth suite, which could
> be mistaken for a hardware result.
> 
> Later patches in this series look like they resolve this:
> 
> - "selftests: xsk: run one test case per xskxceiver invocation" removes
>   test_xsk.sh and xsk_prereqs.sh in favour of test_xsk.py.
> 
> - "selftests: xsk: run the RX and TX endpoints in separate processes"
>   makes parse_command_line() take a single interface. It calls
>   print_usage() when the role, peer host, peer port, test or mode is
>   missing.
> 
> So the problem seems limited to this commit, for example while bisecting.

These are correct statements, however I wouldn't expect us to be hunting
down the bugs while bisecting onto this particular commit as it is putting
the tool into transitional state and as it is said above, future commits
take care of this.

Let me see if I will be so clever with providing justifications onto
further reports on this series ;)

> 
> -- 
> Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261014184539.774708-1-maciej.fijalkowski%40intel.com