From: Eduard Zingerman <eddyz87@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@linux.dev>,
Kernel Team <kernel-team@fb.com>,
Yonghong Song <yonghong.song@linux.dev>,
Nick Zavaritsky <mejedi@gmail.com>
Subject: Re: [PATCH bpf 3/4] bpf: track changes_pkt_data property for global functions
Date: Mon, 09 Dec 2024 17:24:40 -0800 [thread overview]
Message-ID: <8f620e10edd75367fbb9e2cd47eb40872350eefb.camel@gmail.com> (raw)
In-Reply-To: <CAADnVQ+RNBq+nHO2J8m-eaZ_5K=dHk7BBOAwk399e+6qwoybUA@mail.gmail.com>
On Mon, 2024-12-09 at 16:48 -0800, Alexei Starovoitov wrote:
[...]
> Also either inline global sub-prog traversal or the simple rule above
> both suffer from the following issue:
> in case prog_array is empty map->changes_pkt_data will be false.
> It will be set to true only when the first
> prog_fd_array_get_ptr()->bpf_prog_map_compatible()
> will record changes_pkt_data from the first prog inserted in prog_array.
>
> So main prog reading skb->data after calling subprog that tail_calls
> somewhere should assume that skb->data is invalidated.
Yes, that's what I was planning to do.
> That's pretty much your rule "every tail call changes packet data".
>
> I think we can go with this simplest approach as well.
> The test you mentioned have to be adjusted. Not a big deal.
>
> Or we can do:
> "if prog_array empty assume adjusts_pkt_data == true,
> otherwise adj_pkt_data | = for each map in used_maps {
> map->owner.adj_pkt_data }"
>
> The fancy inline global subprog traversal would have to have the same
> "simple" (or call it dumb) rule.
> So at the end both inline or check_cfg are not accurate at all,
> but check_cfg approach is so much simpler.
I don't like the '|= map->owner.adj_pkt_data' thing, tbh.
I think "any tail call changes packet data" is simpler to reason about.
But then, the question is, how to modify the test?
You suggested bpf_xdp_adjust_meta(xdp, 0) for 'xdp', and it is a good fit,
as it does not do much.
For 'skb' I don't see anything better than 'bpf_skb_pull_data(sk, 0)',
it does skb_ensure_writable(), but everything else does more.
Dedicated kfunc would be cleaner, though.
next prev parent reply other threads:[~2024-12-10 1:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-06 4:03 [PATCH bpf 0/4] bpf: track changes_pkt_data property for global functions Eduard Zingerman
2024-12-06 4:03 ` [PATCH bpf 1/4] bpf: add find_containing_subprog() utility function Eduard Zingerman
2024-12-06 4:03 ` [PATCH bpf 2/4] bpf: refactor bpf_helper_changes_pkt_data to use helper number Eduard Zingerman
2024-12-06 4:03 ` [PATCH bpf 3/4] bpf: track changes_pkt_data property for global functions Eduard Zingerman
2024-12-06 20:43 ` Alexei Starovoitov
2024-12-06 21:35 ` Eduard Zingerman
2024-12-09 7:40 ` Eduard Zingerman
2024-12-09 16:53 ` Alexei Starovoitov
2024-12-09 17:57 ` Eduard Zingerman
2024-12-10 0:48 ` Alexei Starovoitov
2024-12-10 1:24 ` Eduard Zingerman [this message]
2024-12-10 1:38 ` Alexei Starovoitov
2024-12-06 4:03 ` [PATCH bpf 4/4] selftests/bpf: test for changing packet data from " Eduard Zingerman
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=8f620e10edd75367fbb9e2cd47eb40872350eefb.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
--cc=martin.lau@linux.dev \
--cc=mejedi@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.