Skip to content

[FRR]Adding fix for memory leak seen with BGP community #18272

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Apr 15, 2024

Conversation

dgsudharsan
Copy link
Collaborator

Why I did it

Porting fix for FRRouting/frr#15459

Adding patch for PR FRRouting/frr#15466

Work item tracking
  • Microsoft ADO (number only):

How I did it

Ported the fix FRRouting/frr#15466 to 8.5.1

How to verify it

Running the test_stress_route and ensure no memory leak

Which release branch to backport (provide reason below if selected)

  • 201811
  • 201911
  • 202006
  • 202012
  • 202106
  • 202111
  • 202205
  • 202211
  • 202305

Tested branch (Please provide the tested image version)

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

@dgsudharsan dgsudharsan requested a review from lguohan as a code owner March 6, 2024 02:10
- if (!bgp_check_withdrawal(bgp, dest))
+ if (!bgp_check_withdrawal(bgp, dest)) {
+ struct attr *adv_attr =
+ bgp_attr_intern(&attr);
Copy link
Contributor

@StormLiangMS StormLiangMS Mar 6, 2024

Choose a reason for hiding this comment

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

hi @dgsudharsan by comparing the diff, we think there is one issue in the patch. after line 186 else, we think in that part, we also need a bgp_attr_flush(attr). because the leaked community allocated from subgroup_announce_check function, after this function, need to consider the flush. but in this patch at line 715, it only flush after !bgp_check_withdrawal, it may not enough. Could you help to check below snippet from Liping's patch?

image

Copy link
Contributor

Choose a reason for hiding this comment

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

Based on our understanding and test results, we still believe that using bgp_attr_unintern here is the better solution.
After shutdown all BGP neighbors, it would be more reasonable if the output of "show bgp community-info" is empty.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hi @donaldsharp Can you please check this?

bgp_attr_intern(&attr);

- bgp_adj_out_set_subgroup(
+ if (!bgp_adj_out_set_subgroup(
Copy link
Contributor

Choose a reason for hiding this comment

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

@dgsudharsan as we discussed,

  1. No need to check the return value of this function, either true or false, we need to free.
  2. In the line 376, to replace bgp_attr_flush with bgp_attr_unintern, which is coupled with bgp_attr_intern.
  3. In the else branch, to add the bgp_attr_flush.

Copy link
Contributor

Choose a reason for hiding this comment

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

Seems the latest patch still checking the function and no flush in the else patch, Could you please help to double confirm, thanks a lot.

@dgsudharsan
Copy link
Collaborator Author

@StormLiangMS @lipxu Can you please review and signoff?

@lipxu
Copy link
Contributor

lipxu commented Mar 26, 2024

@StormLiangMS @lipxu Can you please review and signoff?

Sorry for late response, will verify it in these two days, and let you know if any update, thanks.

+ if (peer->sort == BGP_PEER_EBGP &&
+ (ROUTE_MAP_OUT_NAME(filter) || PREFIX_LIST_OUT_NAME(filter) ||
+ FILTER_LIST_OUT_NAME(filter) || DISTRIBUTE_OUT_NAME(filter) ||
+ UNSUPPRESS_MAP_NAME(filter)))
Copy link
Contributor

Choose a reason for hiding this comment

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

Hi, @dgsudharsan , seems there was UNSUPPRESS_MAP_NAME(filter) in the first commit, but removed in the final version, is it expected? thanks.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hi @donaldsharp can you please help answer this?

Choose a reason for hiding this comment

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

it is missing, but the fix it came from 6814401c47b948a50 is a fix that is not related to the actual memory leak. It is related to allowing a unsuppress-map as a valid outgoing policy. Where it was not allowed before.

@vjardin
Copy link

vjardin commented Mar 28, 2024

For information, why does it require a specific patch instead of Sonic that could consume an official maintenance branch of FRR ?

@dgsudharsan
Copy link
Collaborator Author

For information, why does it require a specific patch instead of Sonic that could consume an official maintenance branch of FRR ?

SONiC's methodology is to consume official release tags from FRR and then integrate any required fixes on top of it. In this case the last updated version was 8.5.1. This patch was made created only recently and can only be added as patch on top of 8.5.1. Later when SONiC picks in a stable official version of FRR which contains the patch, the patch would be removed.

@dgsudharsan dgsudharsan requested a review from lipxu April 8, 2024 21:55
@dgsudharsan
Copy link
Collaborator Author

@lipxu @StormLiangMS Can you please help prioritize and close the review?

@dgsudharsan
Copy link
Collaborator Author

dgsudharsan commented Apr 9, 2024

Thank you @lipxu for testing and approving this PR. @StormLiangMS Can you please help to merge this PR? I will create one for 202311 and will have this patch for master in 8.5.4 upgrade

Copy link
Contributor

@StormLiangMS StormLiangMS left a comment

Choose a reason for hiding this comment

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

LGTM

@StormLiangMS StormLiangMS merged commit 5408251 into sonic-net:202305 Apr 15, 2024
@StormLiangMS
Copy link
Contributor

hi @dgsudharsan do you have PR for 202311?

@dgsudharsan
Copy link
Collaborator Author

Hi @StormLiangMS Here is PR for 202311 #18606

StormLiangMS pushed a commit that referenced this pull request Apr 18, 2024
Porting PR #18272 to 202311.

Why I did it
Porting fix for FRRouting/frr#15459

Adding patch for PR FRRouting/frr#15466

Work item tracking
Microsoft ADO (number only):
How I did it
Ported the fix FRRouting/frr#15466 to 8.5.1

How to verify it
Running the test_stress_route and ensure no memory leak
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants