Re: Packet pointer invalidation and subprograms

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 6 Dec 2024 at 19:30, Alexei Starovoitov
<alexei.starovoitov@xxxxxxxxx> wrote:
>
> On Fri, Dec 6, 2024 at 10:24 AM Kumar Kartikeya Dwivedi
> <memxor@xxxxxxxxx> wrote:
> >
> > I think Andrii has a good point here, this would be an entirely
> > plausible scenario,
> > and with summarization alone we would reject such freplace. Then, the user,
> > due to the lack of explicit tagging, will insert an extra helper call
> > that does nothing
> > just to indicate "invalidates all packets" side effect when it could
> > have been done explicitly.
> > So in effect they just explicitly declared their intent, not through a
> > tag, but through code.
>
> Exactly and that's how it should be done. Through the code.
> C is the language to do that. Magic tag is an extra language hack
> that people need to learn, remember, teach others, etc.

I agree that ascertaining stuff from C itself is friendlier with no
extra burden,
but that is only as long as the C expression itself has a clear meaning.

When you need to write extra stuff to tell the verifier something, C
or not C doesn't really matter.
Like your example, people will still need to remember and tell others
that to ensure they can freplace
with a pkt invalidating global prog, they need this dummy
bpf_skb_pull_data trick.

The medium used to express the intent at that point matters less,
the bigger picture is that the user still needs to communicate it somehow.

We can agree or disagree whether tags are the better or worse way to
do it, but you're doing the same thing in both cases.

>
> We've introduced __arg_ctx and so far the only adopters were
> the programs where Andrii added it by himself.
> Anyone reading it has no idea what __arg* do.
> It's all magic. While C has clear meaning.





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux