Skip to content
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

zebra: Prevent possible wedged fpm write #15025

Merged
merged 2 commits into from
Dec 14, 2023

Conversation

donaldsharp
Copy link
Member

An operator is reporting that the dplane_fpm_nl connection has started to accumulate contexts. One such path that could cause this is that the obuf used is full and stays full. This would imply that what ever is on the receiving end has gotten wedged and is not reading from the stream of data being sent it's way. If after 15 seconds of no response, let's declare the connection dead and reset it.

{
struct fpm_nl_ctx *fnc = EVENT_ARG(t);

zlog_warn("%s: Connection unable to write to peer for over %u seconds, reseting",
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: "resetting"

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed

@@ -1411,9 +1430,13 @@ static void fpm_process_queue(struct event *t)
processed_contexts, memory_order_relaxed);

/* Re-schedule if we ran out of buffer space */
if (no_bufs)
if (no_bufs) {
event_add_timer(fnc->fthread->master, fpm_process_queue, fnc, 0,
Copy link
Contributor

Choose a reason for hiding this comment

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

urgh - always dislike the use of "timer" when the code means "event" - could we switch this one?

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah I hated that one too when I saw it. I'll fix it in a subsuquent commit

* Time in seconds that if the other end is not responding
* something terrible has gone wrong. Let's fix that.
*/
#define DPLANE_FPM_NL_WEDGIE_TIME 15
Copy link
Contributor

Choose a reason for hiding this comment

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

excellent - has to go down as one of the best token names in all of FRR

An operator is reporting that the dplane_fpm_nl connection has
started to accumulate contexts.  One such path that could cause
this is that the obuf used is full and stays full.  This would
imply that what ever is on the receiving end has gotten wedged
and is not reading from the stream of data being sent it's way.
If after 15 seconds of no response, let's declare the connection
dead and reset it.

Signed-off-by: Donald Sharp <[email protected]>
The t_dequeue was being enqueued with a timer of 0
this is really an event instead of a timer.  Let's
use that instead.

Signed-off-by: Donald Sharp <[email protected]>
@donaldsharp donaldsharp force-pushed the dplane_fpm_nl_wedgied branch from f132246 to 61af06c Compare December 14, 2023 14:14
@mjstapp
Copy link
Contributor

mjstapp commented Dec 14, 2023

one CI test case failed - rerunning it...

@mjstapp mjstapp merged commit 594be7d into FRRouting:master Dec 14, 2023
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants