On 2/17/26 2:08 PM, Jakub Kicinski wrote:
On Tue, 17 Feb 2026 10:08:29 -0800 Martin KaFai Lau wrote:
quoted
quoted
The reason for the CI test failure.
Make sense, but the early point stays the same: the user-provided skb
can have unexpected data. Either an skb->protocol is not handled here,
or the earlier dst lookup has an error. I don't know what the current
active users left in lwt are. Unless there is an issue with missing
skb_dst() in other mainstream program types (e.g., tc), I would prefer
to add a check in bpf_lwt_push_ip_encap() instead of complicating
bpf_prog_test_run_skb() further.
Can bpf_prog_test_run_skb() simply not support LWT then?
It is a bold move. If we are open to this idea, we can consider to
retire the lwt support completely instead of only retiring lwt in the
test_run_skb alone. I think it will still take time to announce and
deprecate it?
Having fastpath checks for test harness really feels like duct tape
Adding route lookup on ip[v6]_hdr does not work well either and is a
larger duct tape on the test_run_skb side.
An option is to always set skb to 'some' dst (loopback or
ipv6.fib6_null_entry) on all is_lwt cases without doing the lookup. It
is only to get it going. It is a duct tape also imo but maybe a middle
ground.