Skip to content

go: don't hold the metadata mutex and then acquire the channel mutex#626

Merged
djs55 merged 1 commit intomoby:masterfrom
djs55:lock-order
Mar 2, 2023
Merged

go: don't hold the metadata mutex and then acquire the channel mutex#626
djs55 merged 1 commit intomoby:masterfrom
djs55:lock-order

Conversation

@djs55
Copy link
Copy Markdown
Collaborator

@djs55 djs55 commented Mar 2, 2023

Close() holds the channel mutex then calls decrChannelRef which acquires the metadata mutex.

In DumpState() we should not hold the metadata mutex and then acquire the channel mutex.

Close() holds the channel mutex then calls decrChannelRef which acquires
the metadata mutex.

In DumpState() we should not hold the metadata mutex and then acquire
the channel mutex.

Signed-off-by: David Scott <dave@recoil.org>

io.WriteString(w, "Active channels:\n")
for _, c := range channels {
io.WriteString(w, c.String())
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I can see how having a mutex lock in channel.String may be unexpected. 😅

@djs55 djs55 merged commit 6f5de38 into moby:master Mar 2, 2023
@djs55 djs55 deleted the lock-order branch March 2, 2023 09:23
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.

2 participants