All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saket Kumar Bhaskar <skb99@linux.ibm.com>
To: Hari Bathini <hbathini@linux.ibm.com>
Cc: bpf@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	sachinpb@linux.ibm.com, venkat88@linux.ibm.com,
	andrii@kernel.org, eddyz87@gmail.com, mykolal@fb.com,
	ast@kernel.org, daniel@iogearbox.net, martin.lau@linux.dev,
	song@kernel.org, yonghong.song@linux.dev,
	john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
	haoluo@google.com, jolsa@kernel.org, christophe.leroy@csgroup.eu,
	naveen@kernel.org, maddy@linux.ibm.com, mpe@ellerman.id.au,
	npiggin@gmail.com, memxor@gmail.com, iii@linux.ibm.com,
	shuah@kernel.org
Subject: Re: [PATCH bpf-next v2 5/5] selftests/bpf: Fix arena_spin_lock selftest failure
Date: Thu, 4 Sep 2025 13:55:40 +0530	[thread overview]
Message-ID: <aLlNBK9Zm+N4zarF@linux.ibm.com> (raw)
In-Reply-To: <46243c40-8e5e-47d3-97bd-71f29eeb0127@linux.ibm.com>

On Thu, Sep 04, 2025 at 01:39:31PM +0530, Hari Bathini wrote:
> 
> 
> On 29/08/25 10:21 pm, Saket Kumar Bhaskar wrote:
> > For systems having CONFIG_NR_CPUS set to > 1024 in kernel config
> > the selftest fails as arena_spin_lock_irqsave() returns EOPNOTSUPP.
> > 
> > The selftest is skipped incase bpf program returns EOPNOTSUPP,
> > with a descriptive message logged.
> > 
> > Signed-off-by: Saket Kumar Bhaskar <skb99@linux.ibm.com>
> > ---
> >   .../selftests/bpf/prog_tests/arena_spin_lock.c      | 13 +++++++++++++
> >   tools/testing/selftests/bpf/progs/arena_spin_lock.c |  5 ++++-
> >   2 files changed, 17 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/testing/selftests/bpf/prog_tests/arena_spin_lock.c b/tools/testing/selftests/bpf/prog_tests/arena_spin_lock.c
> > index 0223fce4db2b..1ec1ca987893 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/arena_spin_lock.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/arena_spin_lock.c
> > @@ -40,8 +40,13 @@ static void *spin_lock_thread(void *arg)
> >   	err = bpf_prog_test_run_opts(prog_fd, &topts);
> >   	ASSERT_OK(err, "test_run err");
> > +
> > +	if (topts.retval == -EOPNOTSUPP)
> > +		goto end;
> > +
> >   	ASSERT_EQ((int)topts.retval, 0, "test_run retval");
> > +end:
> >   	pthread_exit(arg);
> >   }
> > @@ -63,6 +68,7 @@ static void test_arena_spin_lock_size(int size)
> >   	skel = arena_spin_lock__open_and_load();
> >   	if (!ASSERT_OK_PTR(skel, "arena_spin_lock__open_and_load"))
> >   		return;
> > +
> >   	if (skel->data->test_skip == 2) {
> >   		test__skip();
> >   		goto end;
> > @@ -86,6 +92,13 @@ static void test_arena_spin_lock_size(int size)
> >   			goto end_barrier;
> >   	}
> > +	if (skel->data->test_skip == 2) {
> > +		printf("%s:SKIP: %d CPUs exceed the maximum supported by arena spinlock\n",
> > +		       __func__, get_nprocs());
> > +		test__skip();
> > +		goto end_barrier;
> > +	}
> > +
> >   	ASSERT_EQ(skel->bss->counter, repeat * nthreads, "check counter value");
> >   end_barrier:
> > diff --git a/tools/testing/selftests/bpf/progs/arena_spin_lock.c b/tools/testing/selftests/bpf/progs/arena_spin_lock.c
> > index c4500c37f85e..a475b974438e 100644
> > --- a/tools/testing/selftests/bpf/progs/arena_spin_lock.c
> > +++ b/tools/testing/selftests/bpf/progs/arena_spin_lock.c
> > @@ -37,8 +37,11 @@ int prog(void *ctx)
> >   #if defined(ENABLE_ATOMICS_TESTS) && defined(__BPF_FEATURE_ADDR_SPACE_CAST)
> >   	unsigned long flags;
> > -	if ((ret = arena_spin_lock_irqsave(&lock, flags)))
> > +	if ((ret = arena_spin_lock_irqsave(&lock, flags))) {
> > +		if (ret == -EOPNOTSUPP)
> > +			test_skip = 2;
> >   		return ret;
> 
> test_skip being set to `1` when the test runs seems counter intuitive.
> How about setting test_skip to `0` when run conditions are met
> and test_skip=1 if run conditions are not met and
> test_skip=2 when operation is not supported?
> 
> - Hari
That seems reasonable to me, but right now -EOPNOTSUPP is also
returned when run condition is not met i.e.:

  if (CONFIG_NR_CPUS > 1024)
                return -EOPNOTSUPP;

So do we really need test_skip = 2 ?

Thanks,
Saket

  reply	other threads:[~2025-09-04  8:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-29 16:51 [bpf-next v2 0/5] powerpc64/bpf: Add support for bpf arena and arena atomics Saket Kumar Bhaskar
2025-08-29 16:51 ` [PATCH bpf-next v2 1/5] powerpc64/bpf: Implement PROBE_MEM32 pseudo instructions Saket Kumar Bhaskar
2025-09-04  8:16   ` Hari Bathini
2025-08-29 16:51 ` [PATCH bpf-next v2 2/5] powerpc64/bpf: Implement bpf_addr_space_cast instruction Saket Kumar Bhaskar
2025-08-29 16:51 ` [PATCH bpf-next v2 3/5] powerpc64/bpf: Introduce bpf_jit_emit_atomic_ops() to emit atomic instructions Saket Kumar Bhaskar
2025-08-29 16:51 ` [PATCH bpf-next v2 4/5] powerpc64/bpf: Implement PROBE_ATOMIC instructions Saket Kumar Bhaskar
2025-08-29 16:51 ` [PATCH bpf-next v2 5/5] selftests/bpf: Fix arena_spin_lock selftest failure Saket Kumar Bhaskar
2025-09-04  8:09   ` Hari Bathini
2025-09-04  8:25     ` Saket Kumar Bhaskar [this message]
2025-09-04 10:34       ` Saket Kumar Bhaskar
2025-09-02 15:33 ` [bpf-next v2 0/5] powerpc64/bpf: Add support for bpf arena and arena atomics Venkat

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=aLlNBK9Zm+N4zarF@linux.ibm.com \
    --to=skb99@linux.ibm.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=hbathini@linux.ibm.com \
    --cc=iii@linux.ibm.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=mpe@ellerman.id.au \
    --cc=mykolal@fb.com \
    --cc=naveen@kernel.org \
    --cc=npiggin@gmail.com \
    --cc=sachinpb@linux.ibm.com \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=venkat88@linux.ibm.com \
    --cc=yonghong.song@linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.