linux-toradex.git/tools/testing/selftests/wireguard/qemu, branch master

watchdog: softlockup: panic when lockup duration exceeds N thresholds

2026-01-21T03:44:20+00:00

The softlockup_panic sysctl is currently a binary option: panic
immediately or never panic on soft lockups.

Panicking on any soft lockup, regardless of duration, can be overly
aggressive for brief stalls that may be caused by legitimate operations. 
Conversely, never panicking may allow severe system hangs to persist
undetected.

Extend softlockup_panic to accept an integer threshold, allowing the
kernel to panic only when the normalized lockup duration exceeds N
watchdog threshold periods.  This provides finer-grained control to
distinguish between transient delays and persistent system failures.

The accepted values are:
- 0: Don't panic (unchanged)
- 1: Panic when duration >= 1 * threshold (20s default, original behavior)
- N > 1: Panic when duration >= N * threshold (e.g., 2 = 40s, 3 = 60s.)

The original behavior is preserved for values 0 and 1, maintaining full
backward compatibility while allowing systems to tolerate brief lockups
while still catching severe, persistent hangs.

[lirongqing@baidu.com: v2]
  Link: https://lkml.kernel.org/r/20251218074300.4080-1-lirongqing@baidu.com
Link: https://lkml.kernel.org/r/20251216074521.2796-1-lirongqing@baidu.com
Signed-off-by: Li RongQing 
Cc: Eduard Zingerman 
Cc: Hao Luo 
Cc: Jiri Olsa 
Cc: John Fastabend 
Cc: KP Singh 
Cc: Lance Yang 
Cc: Martin KaFai Lau 
Cc: Nicholas Piggin 
Cc: Song Liu 
Cc: Stanislav Fomichev 
Cc: Yonghong Song 
Signed-off-by: Andrew Morton

hung_task: panic when there are more than N hung tasks at the same time

2025-11-12T18:00:14+00:00

The hung_task_panic sysctl is currently a blunt instrument: it's all or
nothing.

Panicking on a single hung task can be an overreaction to a transient
glitch.  A more reliable indicator of a systemic problem is when
multiple tasks hang simultaneously.

Extend hung_task_panic to accept an integer threshold, allowing the
kernel to panic only when N hung tasks are detected in a single scan. 
This provides finer control to distinguish between isolated incidents
and system-wide failures.

The accepted values are:
- 0: Don't panic (unchanged)
- 1: Panic on the first hung task (unchanged)
- N > 1: Panic after N hung tasks are detected in a single scan

The original behavior is preserved for values 0 and 1, maintaining full
backward compatibility.

[lance.yang@linux.dev: new changelog]
Link: https://lkml.kernel.org/r/20251015063615.2632-1-lirongqing@baidu.com
Signed-off-by: Li RongQing 
Reviewed-by: Masami Hiramatsu (Google) 
Reviewed-by: Lance Yang 
Tested-by: Lance Yang 
Acked-by: Andrew Jeffery  [aspeed_g5_defconfig]
Cc: Anshuman Khandual 
Cc: Arnd Bergmann 
Cc: David Hildenbrand 
Cc: Florian Wesphal 
Cc: Jakub Kacinski 
Cc: Jason A. Donenfeld 
Cc: Joel Granados 
Cc: Joel Stanley 
Cc: Jonathan Corbet 
Cc: Kees Cook 
Cc: Liam Howlett 
Cc: Lorenzo Stoakes 
Cc: "Paul E . McKenney" 
Cc: Pawan Gupta 
Cc: Petr Mladek 
Cc: Phil Auld 
Cc: Randy Dunlap 
Cc: Russell King 
Cc: Shuah Khan 
Cc: Simon Horman 
Cc: Stanislav Fomichev 
Cc: Steven Rostedt 
Signed-off-by: Andrew Morton

wireguard: selftests: select CONFIG_IP_NF_IPTABLES_LEGACY

2025-09-12T01:52:21+00:00

This is required on recent kernels, where it is now off by default.
While we're here, fix some stray =m's that were supposed to be =y.

Signed-off-by: Jason A. Donenfeld 
Link: https://patch.msgid.link/20250910013644.4153708-5-Jason@zx2c4.com
Signed-off-by: Jakub Kicinski

wireguard: selftests: remove CONFIG_SPARSEMEM_VMEMMAP=y from qemu kernel config

2025-09-12T01:52:21+00:00

It's no longer user-selectable (and the default was already "y"), so
let's just drop it.

It was never really relevant to the wireguard selftests either way.

Cc: Shuah Khan 
Acked-by: Mike Rapoport (Microsoft) 
Reviewed-by: Lorenzo Stoakes 
Reviewed-by: Liam R. Howlett 
Signed-off-by: David Hildenbrand 
Signed-off-by: Jason A. Donenfeld 
Link: https://patch.msgid.link/20250910013644.4153708-4-Jason@zx2c4.com
Signed-off-by: Jakub Kicinski

selftests: net: Enable legacy netfilter legacy options.

2025-07-25T16:38:55+00:00

Some specified options rely on NETFILTER_XTABLES_LEGACY to be enabled.
IP_NF_TARGET_TTL for instance depends on IP_NF_MANGLE which in turn
depends on IP_NF_IPTABLES_LEGACY -> NETFILTER_XTABLES_LEGACY.

Enable relevant iptables config options explicitly, this is needed
to avoid breakage when symbols related to iptables-legacy
will depend on NETFILTER_LEGACY resp. IP_TABLES_LEGACY.

This also means that the classic tables (Kernel modules) will
not be enabled by default, so enable them too.

Signed-off-by: Florian Westphal 
[bigeasy: Split out the config bits from the main patch]
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Pablo Neira Ayuso

wireguard: selftests: specify -std=gnu17 for bash

2025-05-27T07:06:19+00:00

GCC 15 defaults to C23, which bash can't compile under, so specify gnu17
explicitly.

Signed-off-by: Jason A. Donenfeld 
Link: https://patch.msgid.link/20250521212707.1767879-6-Jason@zx2c4.com
Signed-off-by: Paolo Abeni

wireguard: allowedips: add WGALLOWEDIP_F_REMOVE_ME flag

2025-05-27T07:06:19+00:00

The current netlink API for WireGuard does not directly support removal
of allowed ips from a peer. A user can remove an allowed ip from a peer
in one of two ways:

1. By using the WGPEER_F_REPLACE_ALLOWEDIPS flag and providing a new
   list of allowed ips which omits the allowed ip that is to be removed.
2. By reassigning an allowed ip to a "dummy" peer then removing that
   peer with WGPEER_F_REMOVE_ME.

With the first approach, the driver completely rebuilds the allowed ip
list for a peer. If my current configuration is such that a peer has
allowed ips 192.168.0.2 and 192.168.0.3 and I want to remove 192.168.0.2
the actual transition looks like this.

[192.168.0.2, 192.168.0.3] <-- Initial state
[]                         <-- Step 1: Allowed ips removed for peer
[192.168.0.3]              <-- Step 2: Allowed ips added back for peer

This is true even if the allowed ip list is small and the update does
not need to be batched into multiple WG_CMD_SET_DEVICE requests, as the
removal and subsequent addition of ips is non-atomic within a single
request. Consequently, wg_allowedips_lookup_dst and
wg_allowedips_lookup_src may return NULL while reconfiguring a peer even
for packets bound for ips a user did not intend to remove leading to
unintended interruptions in connectivity. This presents in userspace as
failed calls to sendto and sendmsg for UDP sockets. In my case, I ran
netperf while repeatedly reconfiguring the allowed ips for a peer with
wg.

/usr/local/bin/netperf -H 10.102.73.72 -l 10m -t UDP_STREAM -- -R 1 -m 1024
send_data: data send error: No route to host (errno 113)
netperf: send_omni: send_data failed: No route to host

While this may not be of particular concern for environments where peers
and allowed ips are mostly static, systems like Cilium manage peers and
allowed ips in a dynamic environment where peers (i.e. Kubernetes nodes)
and allowed ips (i.e. pods running on those nodes) can frequently
change making WGPEER_F_REPLACE_ALLOWEDIPS problematic.

The second approach avoids any possible connectivity interruptions
but is hacky and less direct, requiring the creation of a temporary
peer just to dispose of an allowed ip.

Introduce a new flag called WGALLOWEDIP_F_REMOVE_ME which in the same
way that WGPEER_F_REMOVE_ME allows a user to remove a single peer from
a WireGuard device's configuration allows a user to remove an ip from a
peer's set of allowed ips. This enables incremental updates to a
device's configuration without any connectivity blips or messy
workarounds.

A corresponding patch for wg extends the existing `wg set` interface to
leverage this feature.

$ wg set wg0 peer  allowed-ips +192.168.88.0/24,-192.168.0.1/32

When '+' or '-' is prepended to any ip in the list, wg clears
WGPEER_F_REPLACE_ALLOWEDIPS and sets the WGALLOWEDIP_F_REMOVE_ME flag on
any ip prefixed with '-'.

Signed-off-by: Jordan Rife 
[Jason: minor style nits, fixes to selftest, bump of wireguard-tools version]
Signed-off-by: Jason A. Donenfeld 
Link: https://patch.msgid.link/20250521212707.1767879-5-Jason@zx2c4.com
Signed-off-by: Paolo Abeni

wireguard: selftests: cleanup CONFIG_UBSAN_SANITIZE_ALL

2025-05-27T07:06:19+00:00

Commit 918327e9b7ff ("ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL")
removed the CONFIG_UBSAN_SANITIZE_ALL configuration option.
Eliminate invalid configurations to improve code readability.

Reviewed-by: Simon Horman 
Signed-off-by: WangYuli 
Signed-off-by: Jason A. Donenfeld 
Link: https://patch.msgid.link/20250521212707.1767879-2-Jason@zx2c4.com
Signed-off-by: Paolo Abeni

sched/debug: Remove CONFIG_SCHED_DEBUG from self-test config files

2025-03-19T21:23:24+00:00

We leave most of the defconfigs alone (there's over 70 of them),
but let's remove CONFIG_SCHED_DEBUG from the scheduler self-test
Kconfig files.

Signed-off-by: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Juri Lelli 
Cc: Vincent Guittot 
Cc: Dietmar Eggemann 
Cc: Steven Rostedt 
Cc: Ben Segall 
Cc: Mel Gorman 
Cc: Valentin Schneider 
Cc: Linus Torvalds 
Link: https://lore.kernel.org/r/Z9szt3MpQmQ56TRd@gmail.com

timekeeping: Remove CONFIG_DEBUG_TIMEKEEPING

2024-11-02T09:14:31+00:00

Since 135225a363ae timekeeping_cycles_to_ns() handles large offsets which
would lead to 64bit multiplication overflows correctly. It's also protected
against negative motion of the clocksource unconditionally, which was
exclusive to x86 before.

timekeeping_advance() handles large offsets already correctly.

That means the value of CONFIG_DEBUG_TIMEKEEPING which analyzed these cases
is very close to zero. Remove all of it.

Signed-off-by: Thomas Gleixner 
Acked-by: John Stultz 
Link: https://lore.kernel.org/all/20241031120328.536010148@linutronix.de