From: Daniel Borkmann <daniel@iogearbox.net>
To: "Jakub Kicinski" <kuba@kernel.org>,
"Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: David Ahern <dsahern@kernel.org>,
netdev@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [PATCH bpf v2 1/3] bpf_redirect_neigh: Support supplying the nexthop as a helper parameter
Date: Tue, 20 Oct 2020 21:47:24 +0200 [thread overview]
Message-ID: <19519442-7c40-5115-de04-e0616931fa4b@iogearbox.net> (raw)
In-Reply-To: <20201020120128.338595e9@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On 10/20/20 9:01 PM, Jakub Kicinski wrote:
> On Tue, 20 Oct 2020 20:08:18 +0200 Toke Høiland-Jørgensen wrote:
>>> Isn't this backward? The hole could be named in the internal structure.
>>> This is a bit of a gray area, but if you name this hole in uAPI and
>>> programs start referring to it you will never be able to reuse it.
>>> So you may as well not require it to be zeroed..
>>
>> Hmm, yeah, suppose you're right. Doesn't the verifier prevent any part
>> of the memory from being unitialised anyway? I seem to recall having run
>> into verifier complaints when I didn't initialise struct on the stack...
>
> Good point, in which case we have a convenient way to zero the hole
> after nh_family but no convenient way to zero the empty address space
> for IPv4 :) (even though that one only needs to be zeroed for the
> verifier)
Technically, it's uninitialized, so zero or any other garbage from BPF stack's
previous use of the program. We could use couple of __u8 :8 after nh_family to
have an unnamed placeholder (like in __bpf_md_ptr()), or we might as well just
switch to __u32 nh_family and avoid the hole that way (also gets rid of the extra
check) ... given we have the liberty to extend later anyway if ever needed.
next prev parent reply other threads:[~2020-10-20 19:47 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-20 10:51 [PATCH bpf v2 0/3] bpf: Rework bpf_redirect_neigh() to allow supplying nexthop from caller Toke Høiland-Jørgensen
2020-10-20 10:51 ` [PATCH bpf v2 1/3] bpf_redirect_neigh: Support supplying the nexthop as a helper parameter Toke Høiland-Jørgensen
2020-10-20 15:08 ` Daniel Borkmann
2020-10-20 18:08 ` Toke Høiland-Jørgensen
2020-10-20 16:30 ` Jakub Kicinski
2020-10-20 18:08 ` Toke Høiland-Jørgensen
2020-10-20 19:01 ` Jakub Kicinski
2020-10-20 19:47 ` Daniel Borkmann [this message]
2020-10-20 18:12 ` David Ahern
2020-10-20 18:56 ` Jakub Kicinski
2020-10-20 16:34 ` Jakub Kicinski
2020-10-20 18:03 ` Toke Høiland-Jørgensen
2020-10-20 18:14 ` David Ahern
2020-10-20 18:50 ` Jakub Kicinski
2020-10-20 10:51 ` [PATCH bpf v2 2/3] bpf_fib_lookup: optionally skip neighbour lookup Toke Høiland-Jørgensen
2020-10-20 13:49 ` David Ahern
2020-10-20 15:04 ` Daniel Borkmann
2020-10-20 18:10 ` Toke Høiland-Jørgensen
2020-10-20 10:51 ` [PATCH bpf v2 3/3] selftests: Update test_tc_redirect.sh to use the modified bpf_redirect_neigh() Toke Høiland-Jørgensen
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=19519442-7c40-5115-de04-e0616931fa4b@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=bpf@vger.kernel.org \
--cc=dsahern@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=toke@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).