mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: Peilin Ye <yepeilin@google.com>,
	bpf@vger.kernel.org,  linux-arm-kernel@lists.infradead.org
Cc: bpf@ietf.org, Xu Kuohai <xukuohai@huaweicloud.com>,
	David Vernet	 <void@manifault.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann	 <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau	 <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>,
	Yonghong Song	 <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh	 <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@fomichev.me>,
	Hao Luo	 <haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>,
	Jonathan Corbet	 <corbet@lwn.net>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Puranjay Mohan	 <puranjay@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon	 <will@kernel.org>, Quentin Monnet <qmo@kernel.org>,
	Mykola Lysenko	 <mykolal@fb.com>, Shuah Khan <shuah@kernel.org>,
	Josh Don <joshdon@google.com>,  Barret Rhoden <brho@google.com>,
	Neel Natu <neelnatu@google.com>,
	Benjamin Segall <bsegall@google.com>,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 7/8] selftests/bpf: Add selftests for load-acquire and store-release instructions
Date: Tue, 28 Jan 2025 17:06:03 -0800	[thread overview]
Message-ID: <131a817f7f2749e78e527a251ca7971588cf62f8.camel@gmail.com> (raw)
In-Reply-To: <3f2de7c6e5d2def7bdfb091347c1dacea0915974.1737763916.git.yepeilin@google.com>

On Sat, 2025-01-25 at 02:19 +0000, Peilin Ye wrote:
> Add several ./test_progs tests:
> 
>   - atomics/load_acquire
>   - atomics/store_release
>   - arena_atomics/load_acquire
>   - arena_atomics/store_release
>   - verifier_load_acquire/*
>   - verifier_store_release/*
>   - verifier_precision/bpf_load_acquire
>   - verifier_precision/bpf_store_release
> 
> The last two tests are added to check if backtrack_insn() handles the
> new instructions correctly.
> 
> Additionally, the last test also makes sure that the verifier
> "remembers" the value (in src_reg) we store-release into e.g. a stack
> slot.  For example, if we take a look at the test program:
> 
>     #0:  "r1 = 8;"
>     #1:  "store_release((u64 *)(r10 - 8), r1);"
>     #2:  "r1 = *(u64 *)(r10 - 8);"
>     #3:  "r2 = r10;"
>     #4:  "r2 += r1;"	/* mark_precise */
>     #5:  "r0 = 0;"
>     #6:  "exit;"
> 
> At #1, if the verifier doesn't remember that we wrote 8 to the stack,
> then later at #4 we would be adding an unbounded scalar value to the
> stack pointer, which would cause the program to be rejected:
> 
>   VERIFIER LOG:
>   =============
> ...
>   math between fp pointer and register with unbounded min value is not allowed
> 
> All new tests depend on the pre-defined __BPF_FEATURE_LOAD_ACQ_STORE_REL
> feature macro, which implies -mcpu>=v4.

This restriction would mean that tests are skipped on BPF CI, as it
currently runs using llvm 17 and 18. Instead, I suggest using some
macro hiding an inline assembly as below:

	asm volatile (".8byte %[insn];"
	              :
	              : [insn]"i"(*(long *)&(BPF_RAW_INSN(...)))
	              : /* correct clobbers here */);

See the usage of the __imm_insn() macro in the test suite.

Also, "BPF_ATOMIC loads from R%d %s is not allowed\n" and
      "BPF_ATOMIC stores into R%d %s is not allowed\n"
situations are not tested.

[...]

> diff --git a/tools/testing/selftests/bpf/prog_tests/atomics.c b/tools/testing/selftests/bpf/prog_tests/atomics.c
> index 13e101f370a1..5d7cff3eed2b 100644
> --- a/tools/testing/selftests/bpf/prog_tests/atomics.c
> +++ b/tools/testing/selftests/bpf/prog_tests/atomics.c
> @@ -162,6 +162,56 @@ static void test_xchg(struct atomics_lskel *skel)
>  	ASSERT_EQ(skel->bss->xchg32_result, 1, "xchg32_result");
>  }

Nit: Given the tests in verifier_load_acquire.c and verifier_store_release.c
     that use __retval annotation, are these tests really necessary?
     (assuming that verifier_store_release.c tests are modified to read
      stored location into r0 before exit).

> +static void test_load_acquire(struct atomics_lskel *skel)
> +{
> +	LIBBPF_OPTS(bpf_test_run_opts, topts);
> +	int err, prog_fd;
> +
> +	if (skel->data->skip_lacq_srel_tests) {
> +		printf("%s:SKIP:Clang does not support BPF load-acquire\n", __func__);
> +		test__skip();
> +		return;
> +	}
> +
> +	/* No need to attach it, just run it directly */
> +	prog_fd = skel->progs.load_acquire.prog_fd;
> +	err = bpf_prog_test_run_opts(prog_fd, &topts);
> +	if (!ASSERT_OK(err, "test_run_opts err"))
> +		return;
> +	if (!ASSERT_OK(topts.retval, "test_run_opts retval"))
> +		return;
> +
> +	ASSERT_EQ(skel->bss->load_acquire8_result, 0x12, "load_acquire8_result");
> +	ASSERT_EQ(skel->bss->load_acquire16_result, 0x1234, "load_acquire16_result");
> +	ASSERT_EQ(skel->bss->load_acquire32_result, 0x12345678, "load_acquire32_result");
> +	ASSERT_EQ(skel->bss->load_acquire64_result, 0x1234567890abcdef, "load_acquire64_result");
> +}

[...]

> --- a/tools/testing/selftests/bpf/progs/arena_atomics.c
> +++ b/tools/testing/selftests/bpf/progs/arena_atomics.c
[...]

> +SEC("raw_tp/sys_enter")
> +int load_acquire(const void *ctx)
> +{
> +	if (pid != (bpf_get_current_pid_tgid() >> 32))
> +		return 0;

Nit: This check is not needed, since bpf_prog_test_run_opts() is used
     to run the tests.

> +
> +#ifdef __BPF_FEATURE_LOAD_ACQ_STORE_REL
> +	load_acquire8_result = __atomic_load_n(&load_acquire8_value, __ATOMIC_ACQUIRE);
> +	load_acquire16_result = __atomic_load_n(&load_acquire16_value, __ATOMIC_ACQUIRE);
> +	load_acquire32_result = __atomic_load_n(&load_acquire32_value, __ATOMIC_ACQUIRE);
> +	load_acquire64_result = __atomic_load_n(&load_acquire64_value, __ATOMIC_ACQUIRE);
> +#endif
> +
> +	return 0;
> +}

[...]


  reply	other threads:[~2025-01-29  1:06 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-25  2:16 [PATCH bpf-next v1 0/8] Introduce load-acquire and store-release BPF instructions Peilin Ye
2025-01-25  2:17 ` [PATCH bpf-next v1 1/8] bpf/verifier: Factor out atomic_ptr_type_ok() Peilin Ye
2025-01-25  2:18 ` [PATCH bpf-next v1 2/8] bpf/verifier: Factor out check_atomic_rmw() Peilin Ye
2025-01-25  2:18 ` [PATCH bpf-next v1 3/8] bpf: Introduce load-acquire and store-release instructions Peilin Ye
2025-01-29  0:19   ` Eduard Zingerman
2025-01-29 22:04     ` Peilin Ye
2025-01-29 22:42       ` Eduard Zingerman
2025-01-30  3:10         ` Peilin Ye
2025-01-29  1:30   ` Eduard Zingerman
2025-01-29 22:17     ` Peilin Ye
2025-01-30  0:41   ` Alexei Starovoitov
2025-01-30  3:38     ` Peilin Ye
2025-01-25  2:18 ` [PATCH bpf-next v1 4/8] arm64: insn: Add BIT(23) to {load,store}_ex's mask Peilin Ye
2025-01-25  2:19 ` [PATCH bpf-next v1 5/8] arm64: insn: Add load-acquire and store-release instructions Peilin Ye
2025-01-25  2:19 ` [PATCH bpf-next v1 6/8] bpf, arm64: Support " Peilin Ye
2025-01-25  2:19 ` [PATCH bpf-next v1 7/8] selftests/bpf: Add selftests for " Peilin Ye
2025-01-29  1:06   ` Eduard Zingerman [this message]
2025-01-29  2:07     ` Ihor Solodrai
2025-01-29  2:17       ` Eduard Zingerman
2025-01-30  0:03     ` Peilin Ye
2025-02-04  0:30     ` Peilin Ye
2025-02-04  0:52       ` Eduard Zingerman
2025-02-04  1:29         ` Peilin Ye
2025-01-25  2:19 ` [PATCH bpf-next v1 8/8] bpf, docs: Update instruction-set.rst " Peilin Ye
2025-01-30  0:44   ` Alexei Starovoitov
2025-01-30  7:33     ` Peilin Ye

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=131a817f7f2749e78e527a251ca7971588cf62f8.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@ietf.org \
    --cc=bpf@vger.kernel.org \
    --cc=brho@google.com \
    --cc=bsegall@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=joshdon@google.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mykolal@fb.com \
    --cc=neelnatu@google.com \
    --cc=paulmck@kernel.org \
    --cc=puranjay@kernel.org \
    --cc=qmo@kernel.org \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=void@manifault.com \
    --cc=will@kernel.org \
    --cc=xukuohai@huaweicloud.com \
    --cc=yepeilin@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®