bpf: fine-tune work-around for bpf_redirect_neigh() from overlay programs#42052
Merged
julianwiedmann merged 3 commits intomainfrom Oct 10, 2025
Merged
bpf: fine-tune work-around for bpf_redirect_neigh() from overlay programs#42052julianwiedmann merged 3 commits intomainfrom
julianwiedmann merged 3 commits intomainfrom
Conversation
Member
Author
|
/test |
Member
Author
|
I'll want to give this a bit more testing, but think it's good enough for a first round of feedback. This should get us back on track to use |
#42000 limited the usage of bpf_redirect_neigh() from overlay programs, to work-around a kernel bug that causes a memory leak. This bug only manifests when bpf_redirect_neigh() is called without next-hop information - or in Cilium terms, without a preceding FIB lookup. By annotating such specific usage of bpf_redirect_neigh() with a fine-grained capability check, we can otherwise allow the use of bpf_redirect_neigh() from overlay context. Start by introducing the neigh_resolver_without_nh_available() check in all relevant places. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
Currently fib_redirect_*() only performs a FIB lookup if used from XDP
context, since there we don't have access to bpf_redirect_neigh().
Extend this case to also cover the usage from overlay programs, so that we
provide next-hop information to fib_do_redirect() and can therefore use
bpf_redirect_neigh().
While at it switch the code paths to positive logic ("under what
conditions can we do a redirect without next-hop").
Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
With the previous patches the code-base is now smart enough to avoid the problematic usage of bpf_redirect_neigh() without next-hop information. Remove the opt-out from the generic neigh_resolver_available() check, so that overlay programs can use the neighbour redirect - as long as they provide next-hop information. Also remove the fallback checks in the EGW helpers, these helpers are now again always used from a context where neigh_resolver_available() is true. Signed-off-by: Julian Wiedmann <jwi@isovalent.com>
a80d0c9 to
5af724f
Compare
Member
Author
|
/test |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
#42000 limited the usage of bpf_redirect_neigh() from overlay programs, to work-around a kernel bug that causes a memory leak.
This bug only manifests when bpf_redirect_neigh() is called without next-hop information - or in Cilium terms, without a preceding FIB lookup. By annotating such specific usage of bpf_redirect_neigh() with a fine-grained capability check, we can otherwise allow the use of bpf_redirect_neigh() from overlay context.
Fixes: #42086.