Hi Ian, On Thursday, June 2, 2022 at 5:48:18 PM UTC+2 Ian Lance Taylor wrote:
> Can you point to any documentation about the problem. Earlier you > mentioned that there was something in the procfs man page. I didn't > see it, but as the procfs man page is very large I'm sure I just > missed it. > You're not the only one ... it took me years to finally really grok the ramifications of /proc/$PID/root but then it simplified some things regarding accessing other mount namespaces significantly and gives security people nightmares. Alas, examples, as Michael Kerrisk's well-written man pages don't support deep linking, unfortunately. On the quick I found these six examples: - /proc/[pid]/cwd: "*In a multithreaded process, the contents of this symbolic link are not available if the main thread has already terminated (typically by calling pthread_exit(3) <https://man7.org/linux/man-pages/man3/pthread_exit.3.html>).*" - /proc/[pid]/exe: "*In a multithreaded process, the contents of this symbolic link are not available if the main thread has already terminated (typically by calling pthread_exit(3) <https://man7.org/linux/man-pages/man3/pthread_exit.3.html>).*" (Michael is copy and pasting here) - /proc/[pid]/fd/: "*In a multithreaded process, the contents of this symbolic link are not available if the main thread has already terminated (typically by calling pthread_exit(3) <https://man7.org/linux/man-pages/man3/pthread_exit.3.html>).*" (me envisioning Michael starting to wear out Ctrl-V) - (I think he forgot /proc/[pid]/fdinfo/ as one is the other's evil twin; need to poke him in Munich some day) - /proc/[pid]/root: "*In a multithreaded process, the contents of this symbolic link are not available if the main thread has already terminated (typically by calling pthread_exit(3) <https://man7.org/linux/man-pages/man3/pthread_exit.3.html>).*" - /proc/[pid]/task: guess what ... yes ... "*In a multithreaded process, the contents of this symbolic link are not available if the main thread has already terminated (typically by calling pthread_exit(3) <https://man7.org/linux/man-pages/man3/pthread_exit.3.html>).*" While probably the vast majority of Go programs on Linux will never worry about this, system-related tools to some extend will be affected when needing to access the above parts of the /proc filesystem while using goroutines and LockOSThread without unlocking in order to drop tainted threads/tasks. If you call runtime.LockOSThread in an init function, as I mentioned > above, then the initial goroutine will be the one that calls the main > function. > Will this be guaranteed to be on my mythical "T0", the leader thread (also termed thread group leader)? Or could this be another thread? I am still trying to understand whether there really is an asymmetry. > It's true that the Go scheduler assumes that there is no such > asymmetry. If that is incorrect, then we need to fix it. But first > we need a test case or at least some documentation. > There is some asymmetry ... however, I recon the scheduler won't need to consider this as the application developer could ensure proper operation by locking the initial goroutine to the leader task/initial thread -- iff the assumption holds true that the initial goroutine is being executed on the leader task/initial thread. This looks like a good assumption to me unless proven otherwise; unfortunately, that still doesn't explain why my app in production ends up with the initial goroutine/leader task/thread staying in a wrong network namespace and not the one it started in. Of course, there's a really good chance that the mistake is on my side and I even think that there's no 3rd party module involved because I bypass the namespace switching mechanism of the one well-known rtnetlink Go module and instead wrap it into my own implementation that is unit tested as to such hiccups. Also, I have rigid error reporting and logging in place (famous last words of inflated developer self esteem) as I considered switching back namespaces to be a severe issue right from the beginning. Nevertheless, I might well have totally goofed up. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fec314de-e58e-4f59-90ce-332ae5b1a723n%40googlegroups.com.
