Closed stepchowfun closed 1 year ago
Isn't the README giving instructions on how to avoid this scenario from the calling program? https://github.com/vishvananda/netns/blob/16c2fa0b2f57726d0e9e4acd228a63c322954f31/README.md?plain=1#L32
My interpretation of the README was that you need to lock the thread if you are doing multiple operations and you want to prevent switching to a different OS thread between those operations. It was not obvious to me that individual operations are also not expected to be correct without the thread being locked.
Maybe we just need to clarify that in the README rather than adding this code change?
I'm working on a project that uses
netns
, and I noticed that one of our integration tests was flaky. I traced the issue to a race innetns.New
. The issue is that the Go scheduler might move the current goroutine to a different OS thread after the new namespace has been created (and joined), but before the call toGet()
. When this happens, the wrong namespace handle is returned.