Re: [PATCH 2/2] selftests/membarrier: Skip unpermitted membarrier command test if preregistered by libc

[Michael Jeanson]

On 2026-08-03 16:37, Andrew Morton wrote:
> On Mon,  3 Aug 2026 14:49:00 +0200 Chris Gellermann <christian.gellermann@xxxxxxxxxxx> wrote:
>
> > On thread creation, Musl registers the private expedited memory barrier,
> > see pthread_create [1]. Thus, invoking the barrier command will no
> > longer be rejected by the kernel with EPERM. The test checking this will
> > fail. Check if the memory barrier command has been registered and skip
> > the test in this case.

Tested-By: Michael Jeanson <mjeanson@xxxxxxxxxxxx>

> >
>
> Who the heck maintains sched/membarrier?
>
> Short answer: everybody I've ever met.  All are cheerfully cc'ed.
>
> Perhaps finer-tuned answer: Peter.
>
> > --- a/tools/testing/selftests/membarrier/membarrier_test_impl.h
> > +++ b/tools/testing/selftests/membarrier/membarrier_test_impl.h
> > @@ -113,6 +113,16 @@ static int test_membarrier_private_expedited_fail(void)
> >   	int cmd = MEMBARRIER_CMD_PRIVATE_EXPEDITED, flags = 0;
> >   	const char *test_name = "sys membarrier MEMBARRIER_CMD_PRIVATE_EXPEDITED not registered failure";
> >   
> > +	/*
> > +	 * Some C libraries, like Musl, register the private expedited barrier
> > +	 * command when creating a thread. Expecting an EPERM on an unregistered
> > +	 * command will therefore no longer work. Skip the test in this case.
> > +	 */
> > +	if (MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED & membarrier_get_registrations()) {
> > +		ksft_test_result_skip("%s test: Command already registered\n", test_name);
> > +		return 0;
> > +	}
>
> AI review
> (https://sashiko.dev/#/patchset/20260803124900.3328789-1-christian.gellermann@xxxxxxxxxxx)
> thinks that membarrier_get_registrations() can return -1 on old
> kernels, so we should check for that before testing for
> MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED.
>
> Seems nonsensical to me - membarrier_get_registrations() doesn't do that.
>
> And policy (my policy, at least) is that selftests test the kernel
> they're shipped with and anyone who tries to run them against any older
> or newer kernel is all out of luck.
>
>
> That being said, and stepping back a bit, is this test testing
> something which we would test?  If pass/fail depends upon deepest
> details of the chosen libc flavour then perhaps the whole test was
> ill-conceived.  wdyt?

I think it's still somewhat useful to test the behavior of the syscall 
when unregistered at least on libcs that don't have automatic registration.