_ebpf_object_load_native: wait until service is deleted on error #4785
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
Collaborator
Author
lmb
force-pushed
the
load-native-wait-for-deletion
branch
3 times, most recently
from
9846ad1 to
f5ec179
Compare
ebpf-go loads native images via ebpf_object_load_native_by_fds. Contrary to ebpf_object_load_native this function requires the caller to provide memory for map and program fds. If the caller doesn't provide enough space, EBPF_NO_MEMORY is returned along with a sizing hint. The caller is expected to retry with a larger buffer. This behaviour currently breaks for two reasons: first, the error recovery path of _ebpf_object_load_native stops and deletes the service, but does not wait for deletion to complete. This is a problem because each native image can currently only be loaded once. This causes an error when ebpf-go retries the load with larger buffers. Second, the check which issues the EBPF_NO_MEMORY result happens at a point where we can't reliably delete the service since we don't know its name. Fix this by waiting for a service to be deleted on the error path and by pushing the EBPF_NO_MEMORY condition down into _ebpf_object_load_native. The latter requires some creative semantics for count_of_maps and count_of_programs: they now specify the maximum number the caller is willing to accept.
lmb
force-pushed
the
load-native-wait-for-deletion
branch
from
f5ec179 to
ad9c218
Compare
lmb
requested review from
Alan-Jowett,
LakshK98,
dthaler,
matthewige,
mikeagun,
mtfriesen,
poornagmsft,
saxena-anurag and
shankarseal
as code owners
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
ebpf-go loads native images via ebpf_object_load_native_by_fds. Contrary to ebpf_object_load_native this function requires the caller to provide memory for map and program fds. If the caller doesn't provide enough space, EBPF_NO_MEMORY is returned along with a sizing hint. The caller is expected to retry with a larger buffer.
This behaviour currently breaks for two reasons: first, the error recovery path of _ebpf_object_load_native stops and deletes the service, but does not wait for deletion to complete. This is a problem because each native image can currently only be loaded once. This causes an error when ebpf-go retries the load with larger buffers. Second, the check which issues the EBPF_NO_MEMORY result happens at a point where we can't reliably delete the service since we don't know its name.
Fix this by waiting for a service to be deleted on the error path and by pushing the EBPF_NO_MEMORY condition down into _ebpf_object_load_native. The latter requires some creative semantics for count_of_maps and count_of_programs: they now specify the maximum number the caller is willing to accept.