-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpf: improve handling for short packets #25159
bpf: improve handling for short packets #25159
Conversation
/test Job 'Cilium-PR-K8s-1.26-kernel-net-next' hit: #24697 (89.50% similarity) |
As mlh noted, |
/test-1.26-net-next Job 'Cilium-PR-K8s-1.26-kernel-net-next' failed: Click to show.Test Name
Failure Output
Jenkins URL: https://jenkins.cilium.io/job/Cilium-PR-K8s-1.26-kernel-net-next/1990/ If it is a flake and a GitHub issue doesn't already exist to track it, comment Then please upload the Jenkins artifacts to that issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes look good, commit structure is maybe a bit weird? Seems like large portions of your second commit could be discarded/squashed.
bpf/bpf_host.c
Outdated
@@ -828,7 +821,16 @@ do_netdev(struct __ctx_buff *ctx, __u16 proto, const bool from_host) | |||
#endif | |||
#ifdef ENABLE_IPV4 | |||
case bpf_htons(ETH_P_IP): | |||
identity = resolve_srcid_ipv4(ctx, identity, &ipcache_srcid, | |||
/* This is the first time revalidate_data() is going to be called in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you potentially drop this chunk all together? Looks like you nullify it in the next commit anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean like shuffling the second and third patch around? Yeah let's try 🤔.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, looks like you add this chunk, but then delete it in the third commit anyway.
Anyway, its a nit, is just to make the history a bit cleaner.
af_packet can craft packets without linear data. So make sure that we pull the IPv4 header, as resolve_srcid_ipv4() won't do it for us (we call it with from_host = true). Also update the comment to match current behaviour. This aligns the IPv4 path with handle_to_netdev_ipv6(). Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
Don't trust that host traffic arrives with the IP header in the skb's linear space. So have resolve_srcid_ipv*() always pull the necessary data, without differentiating between from-netdev and from-host traffic. This means that for to-netdev traffic we now have two places that can handle the traffic. This is just temporary, and will go away with the next patch. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
resolve_srcid_ipv*() is meant to return an __u32, that represents the srcid. But it currently also validates the IP header, and returns DROP_INVALID from that. We use this value without further checks. Fix things up by performing the IP header validation & error handling outside the helper. Note that the to-netdev path already contains a revalidate_data_pull() call, so it's safe to lose this additional one inside resolve_srcid_ipv*(). Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
09b6526
to
e0b9fc2
Compare
/test |
Align the different packet paths in how they handle traffic where the IP header is not in the skb's linear data.