linux-stable.git/tools/testing/selftests/drivers, branch v7.2.6

selftests: drv-net: so_txtime: fix qdisc replace with handle

2026-09-14T11:40:44+00:00

[ Upstream commit dbf34acdfb29781dd4a8a86f7111d99c016fc7e8 ]

The blamed commit updated a tc replace command by adding a handle.

  -    tc(f"qdisc replace dev {ifname} root {qdisc} {optargs}")
  +    tc(f"qdisc replace dev {ifname} root handle 1: {qdisc} {optargs}")

This breaks the test if the root qdisc already has that handle and is of
different kind, with

  "Invalid qdisc name: must match existing qdisc."

If no handle is asked, or the kind differs, tc replace removes the old
qdisc and grafts a new one.

If a handle is asked and exists, tc replace tries to change the qdisc
in place, for which the kind must be the same.

It does not trigger in all setups, like netdevsim or debian 13, which
do not have root handle 1:. But it is a common root handle.

Solve the bug by first deleting the existing root qdisc if one exists.

Wrap that command in a try block, because it will fail for default
qdiscs with handle 0: with

  "Error: Cannot delete qdisc with handle of zero."

Reported-by: Jakub Kicinski 
Closes: https://lore.kernel.org/netdev/20260810183118.32d5c06a@kernel.org/
Fixes: ef3d6cca02c8 ("selftests: drv-net: so_txtime: only send test traffic to sch_etf")
Signed-off-by: Willem de Bruijn 
Link: https://patch.msgid.link/20260811182856.2702163-1-willemdebruijn.kernel@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

selftests: drv-net: so_txtime: only send test traffic to sch_etf

2026-09-14T11:40:37+00:00

[ Upstream commit ef3d6cca02c8a7b6465fb1691823524b86d1cb99 ]

The ETF qdiscs drops traffic without a socket or txtime. Even with
parameter skip_sock_check regular traffic is affected by ETF.

This test ran fine when run manually in a pure software environment.
But with drv-net across two hosts tests fail as early as when calling
cfg.remote.deploy due to effectively losing connectivity.

Isolate the intended test traffic:
- mark that with SO_MARK 100
- install a regular permissive root prio qdisc for background traffic
- install the ETF qdisc as leaf
- install a filter that only directs SO_MARK 100 traffic to this leaf

Technically other high prio traffic will map onto this leaf based on
ToS band mapping too. But that is immaterial in practice.

Fixes: 5c6baef3885c ("selftests: drv-net: convert so_txtime to drv-net")
Signed-off-by: Willem de Bruijn 
Link: https://patch.msgid.link/20260808160129.890119-1-willemdebruijn.kernel@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

selftests: drv-net: Test queue stall upon reconfig

2026-09-14T11:40:37+00:00

[ Upstream commit c98610c2eb7002436f6fca55b21c63200644549a ]

Add a reconfig_tx_stall test that detects the possibility of a TX stall
after ring reconfiguration. The key observation is that drivers using
netif_tx_start_all_queues() are prone to experiencing a stall when
reconfiguration completes compared to drivers using
netif_tx_wake_all_queues(). start_all_queues only clears DRV_XOFF, while
wake_all_queues also calls __netif_schedule() to kick the qdisc. Without
the kick, qdisc backlog present at reconfig time can stay stuck until a
new trigger is issued.

The test caps the TX ring at 64 entries so it fills quickly, then
installs FQ on a target TX queue and sends UDP packets with SO_TXTIME
scheduled in the future. With napi_defer_hard_irqs slowing completions,
the small ring can fill when FQ releases the burst, leaving requeued
qdisc backlog with no FQ timer to rescue it. A subsequent ring reconfig
must wake the queues to drain the backlog. Simply starting the queues can
leave it stuck.

Some drivers lack backpressure on the TX path and may not be able to
build up the qdisc backlog the test relies on. In that case report an
expected failure (xfail) instead of a hard failure.

Testing on some of the existing drivers: Driver-A does not have the bug,
Driver-B has the bug, Driver-C had the bug but it is fixed now.

Driver-A:
./drivers/net/ring_reconfig.py -t reconfig_tx_stall
TAP version 13
1..1
 Sent 1024 SO_TXTIME packets (+100ms)
 Backlog before reconfig: 1176378 bytes
ok 1 ring_reconfig.reconfig_tx_stall
 Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0

Driver-B:
TAP version 13
1..1
 Sent 128 SO_TXTIME packets (+100ms)
 Sent 128 SO_TXTIME packets (+200ms)
 Backlog before reconfig: 148372 bytes
 Check| At ./drivers/net/ring_reconfig.py, line 397, in reconfig_tx_stall:
 Check|     ksft_eq(0, backlog,
 Check failed 0 != 148372 qdisc backlog stuck on queue 1 after ring ....
not ok 1 ring_reconfig.reconfig_tx_stall
 Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0

Driver-C:
TAP version 13
1..1
 Sent 128 SO_TXTIME packets (+100ms)
 Backlog before reconfig: 192278 bytes
ok 1 ring_reconfig.reconfig_tx_stall
 Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0

Signed-off-by: Mohsin Bashir 
Link: https://patch.msgid.link/20260731021543.1058526-1-mohsin.bashr@gmail.com
Signed-off-by: Jakub Kicinski 
Stable-dep-of: ef3d6cca02c8 ("selftests: drv-net: so_txtime: only send test traffic to sch_etf")
Signed-off-by: Sasha Levin

Merge tag 'char-misc-7.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

2026-07-26T17:47:58+00:00

Pull char/misc driver fixes from Greg KH:
 "Here are a number of small char/misc/etc driver fixes for 7.2-rc5 that
  resolve a bunch of different reported issues. Included in here are:

   - rust_binder error message reporting fix

   - stratix10-svc firmware driver fixes

   - mei driver fix

   - intel_th hardware tracing driver fix

   - comedi driver fix

   - uio_hv_generic driver fix

   - ntsync selftest fix

   - nsm misc driver fix

   - some MAINTAINER file updates

  All of these have been in linux-next for over a week with no reported
  issues"

* tag 'char-misc-7.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  MAINTAINERS: Update wine-devel list address
  rust_binder: only print failure if error has source
  intel_th: fix MSC output device reference leak
  misc: nsm: pin the module while the device is open
  mei: bus: access mei_device under device_lock on cleanup
  misc: nsm: only unlock nsm_dev on post-lock error paths
  selftests: ntsync: correct CONFIG_NTSYNC name
  comedi: comedi_parport: deal with premature interrupt
  uio_hv_generic: Bind to FCopy device by default
  MAINTAINERS: Add Greg Kroah-Hartman to GPIB
  firmware: stratix10-svc: fix teardown order in remove to prevent race
  firmware: stratix10-svc: handle NO_RESPONSE in async poll
  firmware: stratix10-svc: fix FCS SMC call kernel-doc
  firmware: stratix10-svc: fix memory leaks and list corruption bugs

selftests: netconsole: ignore busywait errors

2026-07-21T22:01:30+00:00

In these netconsole tests, bash is used with errexit (set -e). It means
that if the busywait timeout, the tests finish without printing an error
message.

It is fine to ignore these errors, because the following validate_xxx
helpers will check the content of the output file, and exit with an
appropriated error message, e.g. FAIL: File was not generated.

Signed-off-by: Matthieu Baerts (NGI0) 
Reviewed-by: Breno Leitao 
Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-7-a2915c294ef5@kernel.org
Signed-off-by: Jakub Kicinski

selftests: drv-net: add missing kconfig for psp.py

2026-07-21T22:01:30+00:00

This psp.py selftest was failing on my side when only using the
drivers/net config file on top of the default one -- the recommended way
to execute selftest targets.

It looks like some kernel config are needed to execute the new tc
commands.

Note that this was not visible on NIPA, because these tests are executed
with the drivers/net/hw ones, combining the two config files, and the hw
one contains the missing ones.

Fixes: 3f74d5bb807e ("selftests/net: Add env for container based tests")
Signed-off-by: Matthieu Baerts (NGI0) 
Reviewed-by: Wei Wang 
Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-6-a2915c294ef5@kernel.org
Signed-off-by: Jakub Kicinski

selftests: drv-net: increase timeout

2026-07-21T22:01:30+00:00

The default timeout is 45 seconds, that's too low for the xdp.py test.

Indeed, this test can take up to 3 minutes with some debug kernel config
on NIPA. Set a timeout to 6 minutes, just to be on the safe side.

Note that the Fixes tag here points to the introduction of the xdp.py
test because I don't know when this test started to take more than 45
seconds. That's OK because a timeout of 6 minutes is not exaggerated.

Fixes: 1cbcb1b28b26 ("selftests: drv-net: Test XDP_PASS/DROP support")
Signed-off-by: Matthieu Baerts (NGI0) 
Link: https://patch.msgid.link/20260710-net-sft-fix-containers-v1-5-a2915c294ef5@kernel.org
Signed-off-by: Jakub Kicinski

selftests: ntsync: correct CONFIG_NTSYNC name

2026-07-17T12:51:16+00:00

The config fragment for these tests defines CONFIG_WINESYNC, which
refers to an earlier name for the ntsync driver before it was merged
[1]. Correct it to define CONFIG_NTSYNC instead.

[1] https://lore.kernel.org/all/f4cc1a38-1441-62f8-47e4-0c67f5ad1d43@codeweavers.com/

Fixes: 7f853a252cde ("selftests: ntsync: Add some tests for semaphore state.")
Cc: stable 
Signed-off-by: Ethan Nelson-Moore 
Reviewed-by: Elizabeth Figura 
Link: https://patch.msgid.link/20260609175505.19632-1-enelsonmoore@gmail.com
Signed-off-by: Greg Kroah-Hartman

selftests: netconsole: only restore MAC when it changed on resume

2026-07-17T11:15:20+00:00

The "mac" bind mode reactivation downs the interface, restores the saved
MAC and renames it to trigger a target resume. This assumes the recreated
interface comes back with a different MAC, which is true under
MACAddressPolicy=none (as on the Netdev CI) but not when MACs are
persistent. In the persistent case netconsole resumes the target on its
own, and the down/restore/rename flow instead drops it and fails the test.

Guard the block on the MAC having actually changed so the test passes
under both policies.

Fixes: 6ecc08329bab ("selftests: netconsole: validate target resume")
Reported-by: Matthieu Baerts (NGI0) 
Closes: https://lore.kernel.org/netdev/f398373e-2cb4-4649-a491-9763df94d98b@kernel.org/
Signed-off-by: Andre Carvalho 
Tested-by: Matthieu Baerts (NGI0) 
Reviewed-by: Breno Leitao 
Link: https://patch.msgid.link/20260710-netcons-mac-reload-v1-1-3fb1bcc70b4a@gmail.com
Signed-off-by: Paolo Abeni

selftests: drv-net: tso: don't touch dangerous feature bits

2026-07-01T00:23:25+00:00

query_nic_features() detects which offloads depend on tx-gso-partial
by enabling everything, turning tx-gso-partial off, and seeing which
active features drop out. Enabling all hw features is dangerous:
we may end up enabling rx-fcs and loopback for example. For the
ice driver we end up getting into problems with feature dependencies
so the cleanup isn't successful either, and the test exits with
rx-fcs and loopback enabled.

Scope the feature probing just to segmentation bits.

Fixes: 266b835e5e84 ("selftests: drv-net: tso: enable test cases based on hw_features")
Reviewed-by: Pavan Chebbi 
Reviewed-by: Daniel Zahka 
Link: https://patch.msgid.link/20260629233923.2151144-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski