Looks like another flaky libnetwork test; TestCreateParallel. Opened #42582

=== RUN   TestCreateParallel
time="2021-06-29T04:56:20Z" level=warning msg="bridge store not initialized. kv object docker/network/v1.0/bridge/net26/ is not added to the store"
time="2021-06-29T04:56:20Z" level=warning msg="bridge store not initialized. kv object docker/network/v1.0/bridge/net70/ is not added to the store"
    bridge_test.go:1133: Success should be 1 instead: 2
--- FAIL: TestCreateParallel (0.09s)

Can we merge the pull request? The change can fix the potential deadlock, and it seems that it does not have any bad side effects.

Not LGTM

If line 117 happened first, and there is no receiver for ch created at line 108, line 115 might be blocked forever.

Line 117 and 115 are mutually exclusive. If one case executes, the other doesn't.

@songlh what's driving your interest in this? Is there a concrete edge case this resolves that you're running into? If we had a way to reproduce the deadlock, this would be much more interesting.

As it stands, we don't really have enough information here to determine whether this is as critical as you seem to believe it to be, so it would be helpful to get more details.

@tianon this is not critical. The bug is found by our dynamic tool. We just want to know programmers' attitude awards this bug.

This is a bit more tricky to tell what affect this is going to have. I'm hesitant to take this change.

If it's not critical, and we're not 100% sure if there may be side-effects, I'll go ahead and close this one for now. Feel free to continue the discussion though!

Not LGTM

If line 117 happened first, and there is no receiver for ch created at line 108, line 115 might be blocked forever.

Line 117 and 115 are mutually exclusive. If one case executes, the other doesn't.

More precise description should be:
We cannot guarantee ch has a receiver when <-rm.cancel happened in all possible situations. Many rm.ShouldRestart(...) calls directly ignore the channel return value, which directly make ch has no receiver. That's I think making it buffer increase 1 can ensure sending operation will not block its child goroutine.