On Fri, Dec 6, 2024 at 10:30 AM Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> wrote: > > On Fri, 6 Dec 2024 at 19:26, Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > On Fri, Dec 6, 2024 at 9:42 AM Andrii Nakryiko > > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > > > > > Or, *importantly*, if user anticipates that "freplace-ment" BPF > > > program for such subprog might need to invalidate packet pointers, but > > > the default subprog implementation doesn't actually call any of those > > > special helpers, user can just explicitly say that "yes, this subprog > > > should be treated as such that invalidates pkt pointers". With your > > > approach there is no way to even express this, unless you hack default > > > subprog implementation to intentionally have reachable > > > pkt-invalidating helper, but not really call it at runtime. > > > > Exactly. > > This artificial issue can be easily solved without tags. > > The nop subprog can have an empty call to bpf_skb_pull_data(skb, 0). > > And it will be much more obvious to anyone reading the C code > > instead of a magic tag. > > Wouldn't it be less obvious? You would still need a fat comment > explaining why you're doing a dummy bpf_skb_pull_data, because > normally it wouldn't occur if it is to clear pkt pointers, and you > will say it's because it tells the verifier that it invalidates the > packet for the caller. > > It would certainly be clear if we had a bpf_skb_clear_pkt_ptrs, which > would be a verifier built-in and no-op at runtime, but we don't. But > then that's the same as a tag. It's not at all the same. It's C vs our special C language extension that gcc still doesn't support.
