Re: [PATCH 1/1] kernel/locking: Add mutual exclusion self-test

[Haakon Bugge <haakon.bugge@oracle.com>]

> On 24 Aug 2026, at 23:48, John Stultz <jstultz@google.com> wrote:
> 
> On Mon, Aug 24, 2026 at 5:29 AM Haakon Bugge <haakon.bugge@oracle.com> wrote:
> > > On 21 Aug 2026, at 22:42, John Stultz <jstultz@google.com> wrote:
> > >
> > > On Mon, Aug 17, 2026 at 6:03 AM Håkon Bugge <haakon.bugge@oracle.com> 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