[manager/dispatcher] Fix deadlock in dispatcher #2744
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
anshulpundir
changed the title
anshulpundir
commented
Sep 10, 2018
manager/dispatcher/dispatcher.go
Outdated
| @@ -342,6 +342,19 @@ func (d *Dispatcher) Stop() error { | |||
| d.cancel() | |||
| d.mu.Unlock() | |||
|
|
|||
| d.processUpdatesLock.Lock() | |||
| // when we called d.cancel(), there may have been waiters currently | |||
| // waiting. they would be forever sleeping if we didn't call Broadcast here | |||
manager/dispatcher/dispatcher.go
Outdated
| @@ -342,6 +342,19 @@ func (d *Dispatcher) Stop() error { | |||
| d.cancel() | |||
| d.mu.Unlock() | |||
|
|
|||
| d.processUpdatesLock.Lock() | |||
| // when we called d.cancel(), there may have been waiters currently | |||
There was a problem hiding this comment.
there may have been waiters
Maybe also describe who the waiters are?
manager/dispatcher/dispatcher.go
Outdated
| // more waits will start after this Broadcast, because before waiting they | ||
| // check if the context is canceled. | ||
| // | ||
| // if that context cancelation check were not present, it would be possible |
There was a problem hiding this comment.
Its not clear from this description that the waiters actually go on wait() holding the rpcRW. Do we want to clarify that?
There was a rare case where the dispatcher could end up deadlocked when calling stop, which would cause the whole leadership change procedure to go sideways, the dispatcher to pile up with goroutines, and the node to crash. In a nutshell, calls to the Session RPC end up in a (*Cond).Wait(), waiting for a Broadcast that, once Stop is called, may never come. To avoid that case, Stop, after being called and canceling the Dispatcher context, does one final Broadcast to wake the sleeping waiters. However, because the rpcRW lock, which stops Stop from proceeding until all RPCs have returned, was previously obtained BEFORE the call to Broadcast, Stop would never reach this final Broadcast call, waiting on the Session RPCs to release the rpcRW lock, which they could not do until Broadcast was called. Hence, deadlock. To fix this, we simple have to move this final Broadcast to above the attempt to acquire the rpcRW lock, allowing everything to proceed correctly. Signed-off-by: Drew Erny <[email protected]>
dperny
force-pushed
the
fix-dispatcher-deadlock
branch
from
c4f5c5a
to
4f15251
Compare
Codecov Report
@@ Coverage Diff @@
## master #2744 +/- ##
==========================================
+ Coverage 61.68% 61.71% +0.02%
==========================================
Files 134 134
Lines 21888 21888
==========================================
+ Hits 13502 13508 +6
+ Misses 6926 6917 -9
- Partials 1460 1463 +3 |
|
LGTM! |
tiborvass
pushed a commit
to tiborvass/docker
that referenced
this pull request
Sep 22, 2018
This also brings in these PRs from swarmkit: - moby/swarmkit#2691 - moby/swarmkit#2744 - moby/swarmkit#2732 - moby/swarmkit#2729 - moby/swarmkit#2748 Signed-off-by: Tibor Vass <[email protected]>
docker-jenkins
pushed a commit
to docker-archive/docker-ce
that referenced
this pull request
Sep 22, 2018
This also brings in these PRs from swarmkit: - moby/swarmkit#2691 - moby/swarmkit#2744 - moby/swarmkit#2732 - moby/swarmkit#2729 - moby/swarmkit#2748 Signed-off-by: Tibor Vass <[email protected]> Upstream-commit: cce1763d57b5c8fc446b0863517bb5313e7e53be Component: engine
|
How is this tested? |
|
For regressions only using unit/e2e tests, and that’s what we’ll recommend too. It’s a race condition so can’t be predictably reproduced @antonybichon17 |
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.
There was a rare case where the dispatcher could end up deadlocked when
calling stop, which would cause the whole leadership change procedure to
go sideways, the dispatcher to pile up with goroutines, and the node to
crash.
In a nutshell, calls to the Session RPC end up in a (*Cond).Wait(),
waiting for a Broadcast that, once Stop is called, may never come. To
avoid that case, Stop, after being called and canceling the Dispatcher
context, does one final Broadcast to wake the sleeping waiters.
However, because the rpcRW lock, which stops Stop from proceeding until
all RPCs have returned, was previously obtained BEFORE the call to
Broadcast, Stop would never reach this final Broadcast call, waiting on
the Session RPCs to release the rpcRW lock, which they could not do
until Broadcast was called. Hence, deadlock.
To fix this, we simple have to move this final Broadcast to above the
attempt to acquire the rpcRW lock, allowing everything to proceed
correctly.
Signed-off-by: Drew Erny [email protected]