Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Chris Gellermann <christian.gellermann@codasip.com>
Cc: shuah@kernel.org, linux-kselftest@vger.kernel.org,
	richard.weiyang@gmail.com, reddybalavignesh9979@gmail.com,
	linux-kernel@vger.kernel.org,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>
Subject: Re: [PATCH 2/2] selftests/membarrier: Skip unpermitted membarrier command test if preregistered by libc
Date: Mon, 3 Aug 2026 13:37:04 -0700	[thread overview]
Message-ID: <20260803133704.8802e73e1a212364e64f67ee@linux-foundation.org> (raw)
In-Reply-To: <20260803124900.3328789-3-christian.gellermann@codasip.com>

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.
> 

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?



      reply	other threads:[~2026-08-03 20:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03 12:48 [PATCH 0/2] selftests/membarrier: Skip an unregistered memory barrier test on Musl Chris Gellermann
2026-08-03 12:48 ` [PATCH 1/2] selftests/membarrier: Introduce helper to get membarrier command registrations Chris Gellermann
2026-08-03 12:49 ` [PATCH 2/2] selftests/membarrier: Skip unpermitted membarrier command test if preregistered by libc Chris Gellermann
2026-08-03 20:37   ` Andrew Morton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260803133704.8802e73e1a212364e64f67ee@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=bsegall@google.com \
    --cc=christian.gellermann@codasip.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=reddybalavignesh9979@gmail.com \
    --cc=richard.weiyang@gmail.com \
    --cc=rostedt@goodmis.org \
    --cc=shuah@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox