> diff --git a/tools/testing/selftests/bpf/progs/dynptr_fail.c
> b/tools/testing/selftests/bpf/progs/dynptr_fail.c
> index b62773ce5219..aa9374dbdb11 100644
> --- a/tools/testing/selftests/bpf/progs/dynptr_fail.c
> +++ b/tools/testing/selftests/bpf/progs/dynptr_fail.c
> @@ -1232,6 +1232,244 @@ int skb_invalid_data_slice4(struct __sk_buff *skb)
> return SK_PASS;
> }
>
[ ... ]
> +SEC("?tc")
> +__failure __msg("invalid mem access 'scalar'")
> +int skb_pkt_ptr_invalid_after_global_dynptr_write(struct __sk_buff *skb)
> +{
> + __u8 *data = (void *)(long)skb->data;
> + __u8 *data_end = (void *)(long)skb->data_end;
> + struct bpf_dynptr ptr;
> +
> + if (data + 1 > data_end)
> + return SK_DROP;
> +
> + bpf_dynptr_from_skb(skb, 0, &ptr);
> + global_dynptr_helper_write(&ptr);
> +
> + /* this should fail */
> + return *data;
> +}
These new cases all assert __failure with __msg("invalid mem access
'scalar'"), meaning they expect the verifier to invalidate the direct
packet pointer after a skb dynptr write.
This expectation matches the verifier behavior change in the companion
patch 1/2 of the series. That verifier change was rejected during review:
Alexei Starovoitov replied "Nack. You misunderstand what
bpf_is_kfunc_pkt_changing() is doing." and later "There is nothing to
fix.", stating the existing verifier behavior is correct.
If the existing verifier behavior is correct and packet pointers are not
invalidated by these dynptr writes, would these __failure expectations
hold? It looks like they encode the disputed behavior from the rejected
patch 1/2, so should this selftest patch land on its own?
The author appears to have agreed in the discussion and withdrawn the
series. Was this patch intended to be dropped along with patch 1/2?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27565623381
