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

[Michael Jeanson <mjeanson@efficios.com>]

On 2026-08-03 16:37, Andrew Morton wrote:
> On Mon,  3 Aug 2026 14:49:00 +0200 Chris Gellermann <christian.gellermann@codasip.com> 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@efficios.com>

>>
> 
> 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@codasip.com)
> 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.