From: David Ahern <dsahern@kernel.org>
To: Stanislav Fomichev <sdf@google.com>, Gilad Sever <gilad9366@gmail.com>
Cc: martin.lau@linux.dev, daniel@iogearbox.net,
john.fastabend@gmail.com, ast@kernel.org, andrii@kernel.org,
song@kernel.org, yhs@fb.com, kpsingh@kernel.org,
haoluo@google.com, jolsa@kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
mykolal@fb.com, shuah@kernel.org, hawk@kernel.org,
joe@wand.net.nz, eyal.birger@gmail.com,
shmulik.ladkani@gmail.com, bpf@vger.kernel.org,
netdev@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH bpf,v2 0/4] Socket lookup BPF API from tc/xdp ingress does not respect VRF bindings.
Date: Mon, 24 Apr 2023 19:39:01 -0600 [thread overview]
Message-ID: <09814247-07ca-5945-8b6e-9dc1632c1e45@kernel.org> (raw)
In-Reply-To: <CAKH8qBuntApFvGYEs_fU_OAsQeP_Uf2sdrEMAtB4rS6c6fhF9A@mail.gmail.com>
On 4/24/23 11:06 AM, Stanislav Fomichev wrote:
>> - xdp callers would check the device's l3 enslaved state using the new
>> `dev_sdif()`
>> - sock_addr callers would use inet{,6}_sdif() as they did before
>> - cg/tc share the same code path, so when netif_is_l3_master() is true
>> use inet{,6}_sdif() and when it is false use dev_sdif(). this relies
>> on the following
>> assumptions:
>> - tc programs don't run on l3 master devices
this can happen, but I am not sure how prevalent a use case.
>> - cgroup callers never see l3 enslaved devices
egress definitely, not sure on ingress. The code resets the skb->dev
back to the original device in a lot of places in the ip/ipv6 code now.
And ipv6 brings up LLAs and those did not get the device switch so it
could be fairly common.
>> - inet{,6}_sdif() isn't relevant for non l3 master devices
sdif should be 0 and not matched if a netdev is not a l3mdev port.
BTW, in skimming the patches, I noticed patch 3 has bpf_l2_sdif which
seems an odd name to me. It returns a layer 3 device index, not a layer
2 which would be a bridge port. I would stick to the l3 naming for
consistency.
>
> Yeah, that's what I was assuming we should be able to do..
> But we probably need somebody who understands this part better than me
> to say whether the above are safe..
>
> If nobody comments, ignore me and do a v2 with your original approach.
prev parent reply other threads:[~2023-04-25 1:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-20 14:50 [PATCH bpf,v2 0/4] Socket lookup BPF API from tc/xdp ingress does not respect VRF bindings Gilad Sever
2023-04-20 14:50 ` [PATCH bpf,v2 1/4] bpf: factor out socket lookup functions for the TC hookpoint Gilad Sever
2023-04-20 14:50 ` [PATCH bpf,v2 2/4] bpf: Call __bpf_sk_lookup()/__bpf_skc_lookup() directly via " Gilad Sever
2023-04-20 14:50 ` [PATCH bpf,v2 3/4] bpf: fix bpf socket lookup from tc/xdp to respect socket VRF bindings Gilad Sever
2023-04-20 14:50 ` [PATCH bpf,v2 4/4] selftests/bpf: Add tc_socket_lookup tests Gilad Sever
2023-04-20 16:44 ` Stanislav Fomichev
2023-04-21 17:01 ` Daniel Borkmann
2023-04-23 9:31 ` Gilad Sever
2023-04-24 17:06 ` Stanislav Fomichev
2023-04-20 16:42 ` [PATCH bpf,v2 0/4] Socket lookup BPF API from tc/xdp ingress does not respect VRF bindings Stanislav Fomichev
2023-04-23 11:41 ` Gilad Sever
2023-04-24 17:06 ` Stanislav Fomichev
2023-04-25 1:39 ` David Ahern [this message]
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=09814247-07ca-5945-8b6e-9dc1632c1e45@kernel.org \
--to=dsahern@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eyal.birger@gmail.com \
--cc=gilad9366@gmail.com \
--cc=haoluo@google.com \
--cc=hawk@kernel.org \
--cc=joe@wand.net.nz \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mykolal@fb.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@google.com \
--cc=shmulik.ladkani@gmail.com \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=yhs@fb.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 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.