Skip to content

lib: revert addition of vtysh_flush() call in vty_out() #19109

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 2 commits into from
Jul 8, 2025

Conversation

eqvinox
Copy link
Contributor

@eqvinox eqvinox commented Jun 30, 2025

This reverts the vtysh_flush() part of #16672 since it is just plain not permissible to do that. There's a cascaded partial revert of #17571, but that was only a minor adjustment and it remains intact in the general sense.

A better/correct fix would be to do something like engineering a vtysh_try_flush() function; but I'd prefer to not do that on stable versions, so here's a revert to get back to functionally correct before we take another go at the memory spike problem.

cf. #19040 for related discussion (this revert should make that PR unnecessary)

eqvinox added 2 commits June 30, 2025 13:35
This *partially* reverts commit 959dbe2
in order to revert 9112fb3 (which is
not correct.)

The socket buffer sizing changes are left in place.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This partially reverts commit 9112fb3.

It is not permissible/possible to call vtysh_flush() from vty_out() as
it may unexpectedly close the vty.  This is only permitted to happen
during a VTY event triggered from the event loop, not from a vty_out()
call in a random place mid-code.

The socket buffer size changes are left in place.

Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Copy link
Member

@riw777 riw777 left a comment

Choose a reason for hiding this comment

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

looks good

@@ -346,17 +346,8 @@ int vty_out(struct vty *vty, const char *format, ...)
case VTY_SHELL_SERV:
case VTY_FILE:
default:
vty->vty_buf_size_accumulated += strlen(filtered);
Copy link
Contributor

Choose a reason for hiding this comment

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

can we do something more limited, just for instance removing the direct call to "vtysh_flush" ? We might well want to keep the counters that are part of the progressive send logic, for example.

Copy link
Contributor

@mjstapp mjstapp left a comment

Choose a reason for hiding this comment

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

we had some discussion during the 7/8/25 dev call, and we've agreed to take this as a fix for the potential crash, and backport it to 10.3 and 10.4. we'll need to work on a way to restore the progressive output and handle vty errors properly.

@mjstapp
Copy link
Contributor

mjstapp commented Jul 8, 2025

@Mergifyio backport dev/10.4 stable/10.3

Copy link

mergify bot commented Jul 8, 2025

backport dev/10.4 stable/10.3

✅ Backports have been created

@mjstapp mjstapp merged commit 46ba105 into FRRouting:master Jul 8, 2025
17 checks passed
mjstapp added a commit that referenced this pull request Jul 8, 2025
lib: revert addition of vtysh_flush() call in vty_out() (backport #19109)
ton31337 added a commit that referenced this pull request Jul 9, 2025
lib: revert addition of vtysh_flush() call in vty_out() (backport #19109)
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.

3 participants