Skip to content

Conversation

squeed
Copy link
Contributor

@squeed squeed commented Jun 30, 2025

The ipcache aggregates metadata for a given prefix by resource. When
determining the ultimate metadata, it loops through all the
resource-level metadata to determine the value for each property.

This changes the code to flatten all the metadata once. It serves two
purposes:

  1. It fixes a race condition, where we performed metadata reads
    without holding the ipcache metadata lock. Since the values were
    updated in-place, this caused races. Specifically, if a resource was
    deleted for a prefix while injection was happening, this caused
    nil panics.
  2. It prevents needless prefix updates when multiple resources all
    provide the same information. This is particularly prevalent for CIDR
    labels.

As a further optimization, if a given metadata update would not change
the flattened metadata, then we short-cut the prefix update and save an
ipcache iteration.

This includes another commit which fixes an awkward usage of the metadata data that interacted poorly with this change.

Fixes: #40134
Fixes: 495164a

@squeed squeed requested review from a team as code owners June 30, 2025 10:27
@squeed squeed requested review from tommyp1ckles and bimmlerd June 30, 2025 10:27
@maintainer-s-little-helper maintainer-s-little-helper bot added the dont-merge/needs-release-note-label The author needs to describe the release impact of these changes. label Jun 30, 2025
@squeed squeed added kind/bug This is a bug in the Cilium logic. sig/policy Impacts whether traffic is allowed or denied based on user-defined policies. release-note/misc This PR makes changes that have no direct user impact. release-blocker/1.18 This issue will prevent the release of the next version of Cilium. labels Jun 30, 2025
@maintainer-s-little-helper maintainer-s-little-helper bot removed the dont-merge/needs-release-note-label The author needs to describe the release impact of these changes. label Jun 30, 2025
@squeed squeed force-pushed the ipcache-fix-metadata-race branch 2 times, most recently from df92537 to 46d3f4b Compare June 30, 2025 14:19
Copy link
Member

@bimmlerd bimmlerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

few nits in first pass; but this feels rather non-trivial for how late in the cycle we are and I don't feel confident in being the only @cilium/ipcache eyes on it; so if someone else form the team could take a look 🙏

You also mention a race; could you spell that out a bit more explicitly for me so I can retrace it and understand how it's fixed now?

@github-project-automation github-project-automation bot moved this from Proposed to Active in Release blockers Jun 30, 2025
@aanm aanm added this to the 1.18 milestone Jun 30, 2025
Copy link
Member

@christarazi christarazi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the direction of this PR, I had considered something like this previously recently so nice to see it happening now. I have a few comments on top of David's review.

Copy link
Member

@joestringer joestringer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One locking question, the rest are nits.

Main question I'm wondering about beyond this PR is just whether to hold the v1.18.0-rc.0 until we merge this or not. This could provide more time for users to try out this new codepath prior to the v1.18.0 final release. Thoughts?

@squeed
Copy link
Contributor Author

squeed commented Jun 30, 2025

Main question I'm wondering about beyond this PR is just whether to hold the v1.18.0-rc.0 until we merge this or not.

@joestringer Good question. The answer isn't clear. How many -rc releases were you hoping to cut? I would definitely like to either see this in the release, or revert the entire FQDN pre-allocation code. The race here is a ticking time bomb.

I think merging this will be cleaner than reverting all of the FQDN changes. So, I suppose I have a weak vote for "delay rc.0 for a day or two". I'll have an updated version addressing feedback in a few hours.

@joestringer
Copy link
Member

@squeed 👍 Makes sense to me yep. We're planning two RCs, two weeks apart, with the full release in about a month's time. The full milestones list is pinned in the discussions tab.

@squeed squeed force-pushed the ipcache-fix-metadata-race branch from 46d3f4b to dc550a8 Compare June 30, 2025 20:02
@squeed
Copy link
Contributor Author

squeed commented Jun 30, 2025

You also mention a race; could you spell that out a bit more explicitly for me so I can retrace it and understand how it's fixed now?

I updated the description a bit, but the race was thus:

  1. the reader would lock, retrieve the prefixInfo, then unlock. prefixInfo is, however, a map so the returned value is a pointer
  2. while the reader is looping over the set of resources in prefixInfo, another writer removes one of the resources
  3. There is now concurrent reading and writing to the same map, leading to races and, sometimes, nil pointers.

@squeed
Copy link
Contributor Author

squeed commented Jun 30, 2025

/test

Copy link
Member

@joestringer joestringer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Latest version LGTM. One minor nit about not adding a TODO comment.

I dug through the users of the Lock and I agree that the RWMutex seems unnecessary and overoptimizing given the current ipcache usage patterns. Switching to a Mutex looks unlikely to cause a regression as far as I can tell.

@squeed squeed force-pushed the ipcache-fix-metadata-race branch from dc550a8 to 673ab63 Compare July 1, 2025 08:00
@squeed
Copy link
Contributor Author

squeed commented Jul 1, 2025

Whoops. Changed the TODO to a short note. CI was green with zero flakes :-). Let's see if it stays that way.

squeed added 2 commits July 1, 2025 11:00
This wraps the prefixInfo type, which was previously a map, in a struct.
Future commits will add more members.

Adjust some of the functions to be pointer receivers (since the preivous
type, a map, was implicitly a pointer).

Signed-off-by: Casey Callendrello <cdc@isovalent.com>
The ipcache aggregated metadata for a given prefix by resource. When
determining the ultimate metadata, it loops through all the
resource-level metadata to determine the value for each property.

This changes the code to flatten all the metadata once. It serves two
purposes:

1. It fixes a race condition, where we performed metadata reads
   without holding the ipcache metadata lock. Since the values were
   updated in-place, this caused races. Specifically, if a resource was
   deleted for a prefix while injection was happening, this caused
   nil panics.
2. It prevents needless prefix updates when multiple resources all
   provide the same information. This is particularly prevalent for CIDR
   labels.

As a further optimization, if a given metadata update would not change
the flattened metadata, then we short-cut the prefix update and save an
ipcache iteration.

Fixes: cilium#40134
Fixes: 495164a

Signed-off-by: Casey Callendrello <cdc@isovalent.com>
@squeed squeed force-pushed the ipcache-fix-metadata-race branch from 673ab63 to 83db0d0 Compare July 1, 2025 09:00
Copy link
Member

@gandro gandro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, LGTM now!

@squeed
Copy link
Contributor Author

squeed commented Jul 1, 2025

/test

@squeed
Copy link
Contributor Author

squeed commented Jul 1, 2025

CI is green :). Just a review needed for logfields changes.

Copy link
Member

@tklauser tklauser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack on behalf of @cilium/cli for the logfields change. Didn't review the rest in-depth.

@squeed
Copy link
Contributor Author

squeed commented Jul 1, 2025

I'll let @bimmlerd give this another pass, then this should be good.

@aanm aanm merged commit 228a293 into cilium:main Jul 1, 2025
68 checks passed
@github-project-automation github-project-automation bot moved this from Active to Done in Release blockers Jul 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug This is a bug in the Cilium logic. release-blocker/1.18 This issue will prevent the release of the next version of Cilium. release-note/misc This PR makes changes that have no direct user impact. sig/policy Impacts whether traffic is allowed or denied based on user-defined policies.
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

CI: ci-e2e-upgrade: timed out waiting for policy updates to be processed: panic: runtime error in pkg/ipcache
7 participants