Netdev List
 help / color / mirror / Atom feed
From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: "Shung-Hsi Yu" <shung-hsi.yu@suse.com>
Cc: "Zhenzhong Wu" <jt26wzz@gmail.com>, <bpf@vger.kernel.org>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<ast@kernel.org>, <daniel@iogearbox.net>,
	<john.fastabend@gmail.com>, <andrii@kernel.org>,
	<martin.lau@linux.dev>, <song@kernel.org>,
	<yonghong.song@linux.dev>, <kpsingh@kernel.org>,
	<haoluo@google.com>, <jolsa@kernel.org>,
	<menglong8.dong@gmail.com>, <eddyz87@gmail.com>,
	<stable@vger.kernel.org>, <mykolal@fb.com>, <tamird@kernel.org>
Subject: Re: [PATCH bpf-next] selftests/bpf: add helper retval linked scalar pruning selftest
Date: Fri, 12 Jun 2026 10:04:15 -0700	[thread overview]
Message-ID: <DJ78FEGKX5S8.1H2M4C8415L98@gmail.com> (raw)
In-Reply-To: <aivZ9jYGw6QRxLQQ@u94a>

On Fri Jun 12, 2026 at 3:18 AM PDT, Shung-Hsi Yu wrote:
> On Thu, Jun 11, 2026 at 09:55:55AM -0700, Alexei Starovoitov wrote:
>> On Thu Jun 11, 2026 at 9:07 AM PDT, Zhenzhong Wu wrote:
>> > Add a verifier runtime test for a branch pattern where a helper return
>> > value and a related scalar stay live across the same control-flow
>> > sequence. Rust/Aya-generated eBPF can naturally produce this shape when
>> > a match on a helper status keeps data derived before the helper call
>> > live across the same branches. Such code commonly uses the helper return
>> > value in r0, where 0 means success, producing an r0 == 0 / r0 != 0
>> > branch shape.
> [...]
>> > +SEC("tc")
>> > +__description("helper retval linked scalar pruning")
>> > +__success __retval(0)
>> > +__naked void helper_retval_linked_scalar_pruning(void)
>> > +{
>> > +	asm volatile (
>> > +	"r7 = *(u32 *)(r1 + %[__sk_buff_data_end]);"
>> > +	"r5 = *(u32 *)(r1 + %[__sk_buff_data]);"
>> > +	"r7 -= r5;"
>> > +	"r2 = 0;"
>> > +	"r3 = r10;"
>> > +	"r3 += -8;"
>> > +	"r4 = 1;"
>> > +	"call %[bpf_skb_load_bytes];"
>> > +	"r0 += 1;"
>> > +	"r6 = 1;"
>> > +	/* success path keeps r7 independent; failure path links r7 to r0. */
>> > +	"if r0 == 1 goto l0_%=;"
>> 
>> this exercises linked registers with BPF_ADD_CONST logic.
>> We already have such tests. Why do we need this one?
>> How is it different?
>
> BPF_ADD_CONST wasn't what was meant to be tested.
>
> The main logic is r7.id == r0.id only happens on "if r0 == 1 goto l0_%="
> fall through, and does not have such link otherwise. I only check tests
> added in commit c0087d59e504 ("selftests/bpf: tests for per-insn
> sync_linked_regs() precision tracking"), but it doesn't seem like such
> conditional linking was tested. 
>
> The other rational is that this seem like a common pattern that is
> genereated from Rust-based BPF program.
>
>> > +	/* success path keeps r7 independent; failure path links r7 to r0. */
>> > +	"if r0 == 1 goto l0_%=;"
>> > +	"r7 = r0;"
>          ^^^^^^^ conditional scalar linking

Fine, it's a regular register linking without BPF_ADD_CONST.
Still the question remains. I believe:
"We already have such tests. Why do we need this one? How is it different?"


  reply	other threads:[~2026-06-12 17:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-11 16:07 [PATCH bpf-next] selftests/bpf: add helper retval linked scalar pruning selftest Zhenzhong Wu
2026-06-11 16:55 ` Alexei Starovoitov
2026-06-12 10:18   ` Shung-Hsi Yu
2026-06-12 17:04     ` Alexei Starovoitov [this message]
2026-06-11 16:58 ` bot+bpf-ci
2026-06-12  6:32   ` Zhenzhong Wu

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=DJ78FEGKX5S8.1H2M4C8415L98@gmail.com \
    --to=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=jt26wzz@gmail.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=menglong8.dong@gmail.com \
    --cc=mykolal@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=shung-hsi.yu@suse.com \
    --cc=song@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tamird@kernel.org \
    --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