egressgw: fix race with endpoint deletion #26901
Merged
Conversation
This file contains 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
jibi
added
kind/bug
with the current implementation of the workqueue used in the egressgw manager to handle CiliumEndpoint events and retries it's possible to trigger a race where by the time we process an add/update event, the related CiliumEndpoint has already been deleted from the pendingEndpointEvents, resulting in the agent panicing due to a nil access. This commit simplifies how the delete events are handled in order to eliminate the race. Fixes: 9fb24de ("egressgw: retry getIdentityLabels on failure") Co-authored-by: André Martins <andre@cilium.io> Signed-off-by: Gilberto Bertin <jibi@cilium.io>
after the switch to the trigger based reconciliation, the reconciliation can handle multiple type of events in one batch. Update the logic so that we don't end up calling updatePoliciesBySourceIP() twice in case we are processing a batch for both endpoint and policy events. Co-authored-by: André Martins <andre@cilium.io> Signed-off-by: Gilberto Bertin <jibi@cilium.io>
jibi
force-pushed
the
pr/jibi/fix-egressgw-async-eps
branch
2 times, most recently
from
5ed7160
to
728e577
Compare
bimmlerd
approved these changes
Jul 19, 2023
There was a problem hiding this comment.
tried pretty hard to find another race, but I think this is safe - my assumption is that OnUpdateEndpoint and OnDeleteEndpoint are not called concurrently (otherwise it's possible to reorder Add/Delete in such a way that the EP should be there, but isn't). I think that's an ok assumption though.
jibi
force-pushed
the
pr/jibi/fix-egressgw-async-eps
branch
from
728e577
to
5ed7160
Compare
|
removed the explicit deletion of the event from |
|
/test |
aanm
approved these changes
Jul 20, 2023
jibi
added
affects/v1.12
jibi
added
the
ready-to-merge
|
marking this as ready even though the sig-datapath review is missing:
|
21 tasks
nbusseneau
added
the
backport-pending/1.14
nbusseneau
removed
the
needs-backport/1.14
maintainer-s-little-helper
bot
moved this from Needs backport from main
to Backport pending to v1.14
in 1.14.0
nbusseneau
added
backport-done/1.14
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.
with the current implementation of the workqueue used in the egressgw
manager to handle CiliumEndpoint events and retries it's possible to
trigger a race where by the time we process an add/update event, the
related CiliumEndpoint has already been deleted from the
pendingEndpointEvents, resulting in the agent panicing due to a nil
access.
This commit simplifies how the delete events are handled in order to
eliminate the race.
Fixes: 9fb24de ("egressgw: retry getIdentityLabels on failure")