potential data race in p2p/dial.go

[lobottt]

It seems to be a potential data race. Specifically, there are two conflicting operations on the field "dest", where the read operation at: p2p/dail.go:413, and the write operation at: p2p/dail.go:517 A data race may occur when the two functions where the two operations are located are called in parallel.

[holiman]

Yep. The field dest is even commented as such:

	// These fields are private to the task and should not be
	// accessed by dialScheduler while the task is running.
	dest         *enode.Node

But the dial scheduler reaches in and accesses it anyway:

// updateStaticPool attempts to move the given static dial back into staticPool.
func (d *dialScheduler) updateStaticPool(id enode.ID) {
	task, ok := d.static[id]
	if ok && task.staticPoolIndex < 0 && d.checkDial(task.dest) == nil {
		d.addToStaticPool(task)
	}
}

cc @fjl

@lobottt how did you come across this? Manual inspection or running it with --race enabled?

[fjl]

This is a known issue, see here: #23430