> On 24 Aug 2026, at 23:48, John Stultz <[email protected]> wrote: > > 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.
Those are all good points. But I am alluding to, that since you can invoke a shell script in a loop loading/unloading a module, a sysfs interface is strictly not required for testing thoroughly. > > 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. Let's shelf this until v7.3-rc1 comes out and hopefully a maintainer can shed some thoughts on this. Thxs, Håkon
