> On 21 Aug 2026, at 22:42, John Stultz <[email protected]> wrote: > > On Mon, Aug 17, 2026 at 6:03 AM Håkon Bugge <[email protected]> wrote: > > diff --git a/kernel/locking/Makefile b/kernel/locking/Makefile > > index cee1901d4cff8..240084b4abbb7 100644 > > --- a/kernel/locking/Makefile > > +++ b/kernel/locking/Makefile > > @@ -38,3 +38,4 @@ obj-$(CONFIG_QUEUED_RWLOCKS) += qrwlock.o > > obj-$(CONFIG_LOCK_TORTURE_TEST) += locktorture.o > > obj-$(CONFIG_WW_MUTEX_SELFTEST) += test-ww_mutex.o > > obj-$(CONFIG_LOCK_EVENT_COUNTS) += lock_events.o > > +obj-$(CONFIG_MX_TEST) += mx_test.o > > Total bikeshed item, but both CONFIG_MX_TEST and mx_test are not very > obvious names for someone looking at this make file.
I am terrible with names. It's short for Mutual eXclusion. Can of course be spelled out if preferred. [snip] > Apologies, I've not had a chance to apply and try this yet. NP. > So this looks like the test has to be run via module load? It can be run built-in as well, but then only the default test is run. > I almost > never use modules in my test environment, so its often nice to allow > it to be built in and be triggered/re-triggered without having to > unload/reload (assuming this is not something like locktorture which > never finishes - and if that is the case, it might be good to > integrate into the locktorture framework instead of adding a new one). No, this selftest terminates. The script, tools/testing/selftests/locking/mx_test.sh, is written to be robust wrt. module load/unload failures. The reason I prefer to run it as module, is the turn-around time. From an edit, it takes literally only a second to compile the module out-of-tree, another second to copy it to the *updates* on the test server. But if the community prefers that all the tests are run when the test is built-in, the loop looping though the eligible tests can be moved from the script to the C source instead. Thxs, Håkon
