From: sashiko-bot@kernel.org
To: "Avinash Duduskar" <avinash.duduskar@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v7 3/3] selftests/bpf: Add bpf_fib_lookup() VLAN flag tests
Date: Mon, 13 Jul 2026 16:38:26 +0000 [thread overview]
Message-ID: <20260713163826.D70201F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260713162305.1237211-4-avinash.duduskar@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The input netns boundary check in `test_fib_lookup_vlan_netns` is a tautology and cannot detect regressions.
--
--- Patch [3]: [PATCH bpf-next v7 3/3] selftests/bpf: Add bpf_fib_lookup() VLAN flag tests ---
commit dd8cb85eafac54bc022600352c949874324b276d
Author: Avinash Duduskar <avinash.duduskar@gmail.com>
selftests/bpf: Add bpf_fib_lookup() VLAN flag tests
Cover both new VLAN flags in the fib_lookup test. BPF_FIB_LOOKUP_VLAN
reduces a VLAN egress to its physical parent plus the tag, and
BPF_FIB_LOOKUP_VLAN_INPUT scopes the lookup to a VLAN subinterface.
> diff --git a/tools/testing/selftests/bpf/prog_tests/fib_lookup.c b/tools/testing/selftests/bpf/prog_tests/fib_lookup.c
> index bd76589580041..f7361f9a34592 100644
> --- a/tools/testing/selftests/bpf/prog_tests/fib_lookup.c
> +++ b/tools/testing/selftests/bpf/prog_tests/fib_lookup.c
[ ... ]
> @@ -851,0 +852,136 @@ void test_fib_lookup(void)
> +void test_fib_lookup_vlan_netns(void)
> +{
[ ... ]
> + /*
> + * input: the moved device is still in veth7's VLAN group, but it
> + * lives in another netns, so the lookup must fail closed
> + */
> + skb.ifindex = parent_idx;
> + memset(fib_params, 0, sizeof(*fib_params));
> + fib_params->family = AF_INET;
> + fib_params->l4_protocol = IPPROTO_TCP;
> + fib_params->ifindex = parent_idx;
> + fib_params->h_vlan_proto = htons(ETH_P_8021Q);
> + fib_params->h_vlan_TCI = htons(66);
> + if (!ASSERT_EQ(inet_pton(AF_INET, IPV4_VLAN_NETNS_DST, &fib_params->ipv4_dst),
> + 1, "inet_pton(dst)"))
> + goto fail;
> +
> + skel->bss->fib_lookup_ret = -1;
> + skel->bss->lookup_flags = BPF_FIB_LOOKUP_VLAN_INPUT |
> + BPF_FIB_LOOKUP_SKIP_NEIGH;
> + err = bpf_prog_test_run_opts(prog_fd, &run_opts);
> + if (!ASSERT_OK(err, "test_run(input)"))
> + goto fail;
> + ASSERT_EQ(skel->bss->fib_lookup_ret, BPF_FIB_LKUP_RET_NOT_FWDED,
> + "input across netns fails closed");
[Severity: Medium]
Is this test effectively a tautology?
The IP and routing configuration for the target namespace NS_VLAN_B isn't
set up until after this input test runs.
If a kernel bug completely skipped the netns boundary check, wouldn't the
route lookup fail anyway and return BPF_FIB_LKUP_RET_NOT_FWDED, causing this
assertion to falsely pass?
> + ASSERT_EQ(fib_params->ifindex, parent_idx, "ifindex untouched");
> + ASSERT_EQ(fib_params->h_vlan_TCI, htons(66), "tag untouched");
> +
> + close_netns(nstoken);
> + nstoken = open_netns(NS_VLAN_B);
> + if (!ASSERT_OK_PTR(nstoken, "open_netns(b)"))
> + goto fail;
> +
> + /*
> + * egress: the fib result is the VLAN device here, but its parent
> + * is in the other netns, so the swap must not happen
> + */
> + SYS(fail, "ip addr add %s/24 dev veth7.66", IPV4_VLAN_NETNS_ADDR);
> + err = write_sysctl("/proc/sys/net/ipv4/conf/veth7.66/forwarding", "1");
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260713162305.1237211-1-avinash.duduskar@gmail.com?part=3
prev parent reply other threads:[~2026-07-13 16:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 16:23 [PATCH bpf-next v7 0/3] bpf: bidirectional VLAN support for bpf_fib_lookup() Avinash Duduskar
2026-07-13 16:23 ` [PATCH bpf-next v7 1/3] bpf: Add BPF_FIB_LOOKUP_VLAN flag to bpf_fib_lookup() helper Avinash Duduskar
2026-07-13 16:23 ` [PATCH bpf-next v7 2/3] bpf: Add BPF_FIB_LOOKUP_VLAN_INPUT " Avinash Duduskar
2026-07-13 16:23 ` [PATCH bpf-next v7 3/3] selftests/bpf: Add bpf_fib_lookup() VLAN flag tests Avinash Duduskar
2026-07-13 16:38 ` sashiko-bot [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=20260713163826.D70201F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=avinash.duduskar@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.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.