bpf: lxc: avoid upgrade/downgrade woes with CB_FROM_TUNNEL in IPv6 path #29304
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cilium#28920 introduced usage of CB_FROM_TUNNEL in the IPv6 ingress tail-call. But unless all calling programs get upgraded/downgraded in *very* specific order (so that while this version of the tail-call is installed, *all* in-flight skbs have their CB_FROM_TUNNEL populated), some packets potentially miss the tunnel-specific processing that tail_ipv6_policy() is meant to apply. In particular their type might not get switched to PACKET_HOST, resulting in drops with SKB_DROP_REASON_OTHERHOST. So we need to take a two-step approach - first roll out the support for CB_FROM_TUNNEL into all callers, but wait until a subsequent release (1.16) before tail_ipv6_policy() starts using it. Thus even on a downgrade to 1.15, all callers will continue to populate CB_FROM_TUNNEL. Reported-by: Martynas Pumputis <m@lambda.lt> Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
|
/test |
brb
added a commit
that referenced
this pull request
Nov 21, 2023
brb
reviewed
Nov 21, 2023
brb
added a commit
that referenced
this pull request
Nov 22, 2023
julianwiedmann
added a commit
to julianwiedmann/cilium
that referenced
this pull request
Jan 15, 2024
This workaround was added by cilium#29304 to deal with up-/downgrade troubles between v1.14 and v1.15. As the comment says, we can now remove this workaround for the 1.16 devel cycle. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jan 15, 2024
This workaround was added by #29304 to deal with up-/downgrade troubles between v1.14 and v1.15. As the comment says, we can now remove this workaround for the 1.16 devel cycle. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
derailed
pushed a commit
to derailed/cilium
that referenced
this pull request
Jan 24, 2024
This workaround was added by cilium#29304 to deal with up-/downgrade troubles between v1.14 and v1.15. As the comment says, we can now remove this workaround for the 1.16 devel cycle. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#28920 introduced usage of CB_FROM_TUNNEL in the IPv6 ingress tail-call. But unless all calling programs get upgraded/downgraded in very specific order (so that while this version of the tail-call is installed, all in-flight skbs have their CB_FROM_TUNNEL populated), some packets potentially miss the tunnel-specific processing that tail_ipv6_policy() is meant to apply. In particular their type might not get switched to PACKET_HOST, resulting in drops with SKB_DROP_REASON_OTHERHOST.
So we need to take a two-step approach - first roll out the support for CB_FROM_TUNNEL into all callers, but wait until a subsequent release (1.16) before tail_ipv6_policy() starts using it. Thus even on a downgrade to 1.15, all callers will continue to populate CB_FROM_TUNNEL.
Reported-by: Martynas Pumputis m@lambda.lt