discover: adds mutex and lock/unlock logic to prevent race condition

[r4f4ss]

Fix #31460

[fjl]

The reported race is valid, but the fix is not good. The root of the issue is that handleAddNode is called from loadSeedNodes. This function runs in two contexts:

• in Table constructor
• during refresh, on a separate goroutine

In the latter case, it would be more appropriate to call addNode, which will correctly dispatch the node addition request to the Table.loop goroutine. All other access to the tableRevalidation data structure happens from this goroutine, and it was always intended to be used without a lock.

[r4f4ss]

The reported race is valid, but the fix is not good. The root of the issue is that handleAddNode is called from loadSeedNodes. This function runs in two contexts:

• in Table constructor
• during refresh, on a separate goroutine

In the latter case, it would be more appropriate to call addNode, which will correctly dispatch the node addition request to the Table.loop goroutine. All other access to the tableRevalidation data structure happens from this goroutine, and it was always intended to be used without a lock.

Thanks for the clarification.

It seems that Table.doRefresh calls Table.loadSeedNodes which uses a lock to call Table.handleAddNode. The cause seems to be the call of tableRevalidation.run inside Table.loop, which doesn't use any lock.

I think using the Table lock to call revalidationList.schedule inside tableRevalidation.run solves it. Note that the Table lock is already used elsewhere in tableRevalidation.