connmgr: fix concurrent map misuse.

[cachalots]

fix #1847 ipfs/kubo#9374

go-libp2p/p2p/net/connmgr/connmgr.go

Line 450 in 21dc42b

// but since inf.conns is a map, it will still point to the original object

Loop conns is not locked, causing concurrent map misuse.

This repair method needs to modify more code, so I didn't choose to use this method.

type peerInfos  []peerInfo

// replace to
type peerInfos struct {
	peerInfo []peerInfo
	segments segments
}

[marten-seemann]

That doesn't seem like a very intuitive API. peerInfo is just a []peerInfo, and has no (obvious) connection to segments (which just holds a map of peerInfos).

[cachalots]

That doesn't seem like a very intuitive API. peerInfo is just a []peerInfo, and has no (obvious) connection to segments (which just holds a map of peerInfos).

I just put forward this idea. The code just add parameter segments to the method SortByValueAndStreams to get lock.

[p-shahi]

Thanks for the initiative and providing logs @cachalots! I will close this in favor of #1860

[MarcoPolo]

Thanks for looking into this @cachalots. I put a fix here: #1860. It's worth pointing out that this PR has two possible deadlocks.

1. both left and right are in the same segment.
2. goroutine 1 locks A then B, goroutine 2 locks B then A.

s hard Concurrency i.

I'm closing this pr and proceeding with #1860 (feel free to give that a review!), but I appreciate the effort. In the mean time, if you're looking for other places to contribute you could take a look at: #1707 especially since you've already familiarized yourself with the connmgr.