On Mon, Aug 24, 2026 at 5:29 AM Haakon Bugge <[email protected]> wrote: > > 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.
Yeah, I can see the benefit in the case where you're testing on the machine you build with. However, I've found in cases where you're building on a different machine then your testing with, modules can be more of a pain to work with. That's why I've added sysfs interfaces to some tests (test-ww_mutex, and my out of tree ksched_football), so this sort of module-load-time-testing can be repeatedly re-triggered in a static build config. > 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. I'm not sure if there's a clear community preference. Especially as some thought is probably needed as to the sysfs conventions, as littering /sys/kerenel/ with a bunch of test driver interfaces might not be a great long term solution. But this was just something I wanted to raise, as I've found it useful, especially when issues only show up after many many iterations of the test. thanks -john
