From: "Håkon Bugge" <haakon.bugge@oracle.com>
To: linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Boqun Feng <boqun@kernel.org>, Waiman Long <longman@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Shuah Khan <shuah@kernel.org>
Cc: linux-kselftest@vger.kernel.org,
"John Stultz" <jstultz@google.com>,
"Håkon Bugge" <haakon.bugge@oracle.com>
Subject: [PATCH 0/1] kernel/locking: Add mutual exclusion self-test
Date: Mon, 17 Aug 2026 15:02:35 +0200 [thread overview]
Message-ID: <20260817130239.343594-1-haakon.bugge@oracle.com> (raw)
Hi,
Please consider the following patch for the v7.3 merge window.
This patch adds a stress-based selftest for kernel locking and atomic
synchronization primitives. The test runs concurrent workers against
an array of counters while maintaining a simple invariant: every
increment is paired with a decrement, so the sum of all counters must
remain zero.
A common test interface allows the same workload to exercise a range
of locking primitives, including spinlocks and rwlocks, as well as
variants using atomic and bit operations without an explicit
lock. After the workers complete, the module checks the invariant and
reports a failure if the resulting sum is nonzero.
The test provides regression coverage for memory-ordering issues that
may otherwise be difficult to reproduce. In particular, it can expose
the regression fixed by commit 415d83249709 ("locking/atomic: Make
test_and_*_bit() ordered on failure") on weakly ordered architectures
such as ARM. It also includes a variant modeling the incorrect
acquire/release ordering formerly used by RDS before commit
1422f28826d2 ("rds: introduce acquire/release ordering in
acquire/release_in_xmit()"). This variant fails on ARM systems.
The patch also adds a kselftest script that:
* first runs an intentionally unsynchronized variant to verify that the
workload is capable of exposing lost updates;
* obtains the available test variants from the module;
* runs each non-broken variant; and
* supports low, medium, and high effort levels for interactive and CI use.
The module exposes parameters for selecting the test variant, run
duration, number of elements, and data-structure padding. Varying the
padding is useful because the reproducibility of some ordering
failures depends on the relative placement of the tested state in
memory.
A successful run does not prove correctness, but the test provides a
practical way to detect synchronization regressions and reproduce
known classes of ordering bugs under load.
If this commit gets accepted, I have the intention, subject to other
work priorities, to expand on the locking primitives, and in
particular add a double set of ww_mutexes for each counter and attempt
to acquire both in a random order. Using both the Wound-Wait and
Wait-Die variants.
Thxs, Håkon
Håkon Bugge (1):
kernel/locking: Add mutual exclusion self-test
kernel/locking/Makefile | 1 +
kernel/locking/mx_test.c | 707 +++++++++++++++++++++
lib/Kconfig.debug | 9 +
tools/testing/selftests/locking/Makefile | 2 +-
tools/testing/selftests/locking/mx_test.sh | 181 ++++++
5 files changed, 899 insertions(+), 1 deletion(-)
create mode 100644 kernel/locking/mx_test.c
create mode 100755 tools/testing/selftests/locking/mx_test.sh
--
2.43.5
next reply other threads:[~2026-08-17 13:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 13:02 Håkon Bugge [this message]
2026-08-17 13:02 ` [PATCH 1/1] kernel/locking: Add mutual exclusion self-test Håkon Bugge
2026-08-21 20:42 ` John Stultz
2026-08-18 7:54 ` [PATCH 0/1] " Peter Zijlstra
2026-08-18 8:14 ` Haakon Bugge
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=20260817130239.343594-1-haakon.bugge@oracle.com \
--to=haakon.bugge@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=boqun@kernel.org \
--cc=jstultz@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=shuah@kernel.org \
--cc=will@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.