fix double lock bug and cmd resume early bugs #14019
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
The lock/unlocks are being done short-circuit so they are never pending; however, the handling of the unlock notification was always resuming the command if pending was set. In all cases pending is set for another command. For example implicit commit locks then when notified its done unlocks which was clearing the set-config pending flag and resuming that command incorrectly. Signed-off-by: Christian Hopps <chopps@labn.net>
There's a workaround in the code from a bug from back in 2004, it ends and re-enters config mode anytime an `exit` is done from a level below the top-level config node (e.g., from a `router isis` node). We need to re-enter config mode with or without a lock according to how we actually entered it to begin with. fixes FRRouting#13920 Signed-off-by: Christian Hopps <chopps@labn.net>
Signed-off-by: Christian Hopps <chopps@labn.net>
Continuous Integration Result: FAILEDContinuous Integration Result: FAILEDSee below for issues. This is a comment from an automated CI system. Get source / Pull Request: SuccessfulBuilding Stage: SuccessfulBasic Tests: FailedTopotests Ubuntu 18.04 amd64 part 9: Failed (click for details)Topology Test Results are at https://ci1.netdef.org/browse/FRR-PULLREQ2-TOPO9U18AMD64-12952/test Topology Tests failed for Topotests Ubuntu 18.04 amd64 part 9 Successful on other platforms/tests
|
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-12953/ This is a comment from an automated CI system. |
|
@Mergifyio backport dev/9.0 |
✅ Backports have been created
|
Jafaral
added a commit
that referenced
this pull request
Jul 17, 2023
fix double lock bug and cmd resume early bugs (backport #14019)
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.
vtysh: track and fix file-lock use in the workaround from 2004
There's a workaround in the code from a bug from back in 2004, it ends
and re-enters config mode anytime an
exitis done from a level belowthe top-level config node (e.g., from a
router isisnode). We need tore-enter config mode with or without a lock according to how we actually
entered it to begin with.
fixes #13920
lib: mgmtd: only clear pending for the in-progress command
The lock/unlocks are being done short-circuit so they are never pending;
however, the handling of the unlock notification was always resuming the command
if pending was set. In all cases pending is set for another command. For example
implicit commit locks then when notified its done unlocks which was clearing the
set-config pending flag and resuming that command incorrectly.