From: bot+bpf-ci@kernel.org
To: bestswngs@gmail.com,ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,eddyz87@gmail.com,memxor@gmail.com,martin.lau@linux.dev,song@kernel.org,yonghong.song@linux.dev,jolsa@kernel.org,emil@etsalapatis.com,ihor.solodrai@linux.dev,john.fastabend@gmail.com,davem@davemloft.net,edumazet@google.com,kuba@kernel.org,pabeni@redhat.com,horms@kernel.org,shuah@kernel.org
Cc: bpf@vger.kernel.org,linux-kernel@vger.kernel.org,netdev@vger.kernel.org,linux-kselftest@vger.kernel.org,xmei5@asu.edu,bestswngs@gmail.com,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,mason@kernel.org,ihor.solodrai@linux.dev
Subject: Re: [PATCH v4 2/2] selftests/bpf: cover stale CB after LWT IP encapsulation
Date: Mon, 21 Sep 2026 18:38:49 +0000 (UTC) [thread overview]
Message-ID: <5864c45ca5b86f0009ccba65489985cbff9e7e210bf9822aa4875fc027aec12a@mail.kernel.org> (raw)
In-Reply-To: <20260921173910.90847-3-bestswngs@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2488 bytes --]
> diff --git a/tools/testing/selftests/bpf/prog_tests/lwt_ip_encap.c b/tools/testing/selftests/bpf/prog_tests/lwt_ip_encap.c
> index 5c5560d45c5b4..ef90dd8d4b87c 100644
> --- a/tools/testing/selftests/bpf/prog_tests/lwt_ip_encap.c
> +++ b/tools/testing/selftests/bpf/prog_tests/lwt_ip_encap.c
[ ... ]
> @@ -739,3 +739,48 @@ void test_lwt_ip_encap_vxlan_ipv6(void)
> {
> lwt_ip_encap_vxlan(IPV6_ENCAP);
> }
> +
> +void test_lwt_ip_encap_stale_cb(void)
> +{
[ ... ]
> + SYS_NOFAIL("ip netns exec %s ping -q -R -c 1 -W 1 -I veth1 %s >/dev/null 2>&1",
> + ns1, IP4_ADDR_DST);
> + ASSERT_TRUE(skel->bss->stale_cb_seen, "stale_cb_seen");
> + ASSERT_TRUE(skel->bss->stale_cb_cleared, "stale_cb_cleared");
Could the test confirm that the probe packet actually carries an IP option?
Looking at ip_rcv_core() in net/ipv4/ip_input.c, IPCB(skb) is zeroed
unconditionally on receive:
memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
The opt.optlen and opt.rr fields are only written by ip_rcv_options(),
which ip_rcv_finish_core() calls only when the IP header has options:
if (iph->ihl > 5) {
drop_reason = ip_rcv_options(skb, dev);
If ping -R does not place a Record Route option on the wire (a ping
implementation that accepts but ignores -R, an option stripped en route,
or a non-iputils ping), the inner header has ihl == 5, IPCB(skb)->opt
stays all-zero through the LWT run, and the fentry hook records
stale_cb_cleared = true whether or not bpf_lwt_reset_cb() exists.
The stale_cb_seen flag still becomes true, because the ICMP_TIME_EXCEEDED
is produced by the TTL-one outer header the BPF program prepends and does
not depend on options at all, so neither assertion catches the missing
precondition and the test silently stops guarding the fix.
Could a pre-encapsulation check record whether opt.optlen was non-zero,
so the test fails loudly when the probe packet is not what it expects?
For example, an fentry or fexit on bpf_lwt_push_ip_encap that reads
IPCB(skb)->opt.optlen before the reset, then asserts that value was
non-zero.
> +
> +out:
> + test_lwt_ip_encap__destroy(skel);
> + SYS_NOFAIL("ip netns del %s", ns1);
> + SYS_NOFAIL("ip netns del %s", ns2);
> + SYS_NOFAIL("ip netns del %s", ns3);
> +}
[ ... ]
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/35634260486
prev parent reply other threads:[~2026-09-21 18:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 17:39 [PATCH v4 0/2] bpf: clear stale IPv4 options after LWT encapsulation Weiming Shi
2026-09-21 17:39 ` [PATCH v4 1/2] " Weiming Shi
2026-09-21 17:39 ` [PATCH v4 2/2] selftests/bpf: cover stale CB after LWT IP encapsulation Weiming Shi
2026-09-21 18:38 ` bot+bpf-ci [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=5864c45ca5b86f0009ccba65489985cbff9e7e210bf9822aa4875fc027aec12a@mail.kernel.org \
--to=bot+bpf-ci@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bestswngs@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=emil@etsalapatis.com \
--cc=horms@kernel.org \
--cc=ihor.solodrai@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=mason@kernel.org \
--cc=memxor@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=xmei5@asu.edu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®