Change new thread's affinity after thread starts, from the same thread, as a workaround for Snap #40205
Conversation
…d, as a workaround for Snap - Snap's default strict confinement doesn't allow setting the affinity of a different thread, and currently doesn't allow `sched_setaffinity(<nonzeroPid>, ...)`, which pthread implementation calls - Switched to use sched_setaffinity(0, ...) where appropriate Fix for dotnet#1634 in master
|
|
||
| CPU_ZERO(&cpuSet); | ||
|
|
||
| st = sched_getaffinity(gPID, sizeof(cpu_set_t), &cpuSet); |
There was a problem hiding this comment.
A nit - zero instead of gPID should work here too.
There was a problem hiding this comment.
Based on the docs I'm not completely sure that they're the same thing. The previous intention was to get the affinity of the process (or perhaps the thread corresponding with gPID) and apply the same affinity to the new thread. The doc for sched_getaffinity only talks about "process" and not "thread", but I wonder if there is ambiguity there since threads have their own pid the the same way as processes.
There was a problem hiding this comment.
You are actually right, my mistake. The goal of this code is to set the affinity to be the same as the affinity of the main thread (which is identified by the same PID as the process). If we used zero here, the operation would be effectively noop, as it would just get the affinity of the current thread and then set it to the same value.
There was a problem hiding this comment.
I was looking at https://linux.die.net/man/2/sched_getaffinity, it does mention a bit about threads:
The affinity mask is actually a per-thread attribute that can be adjusted independently for each of the threads in a thread group. The value returned from a call to gettid(2) can be passed in the argument pid. Specifying pid as 0 will set the attribute for the calling thread, and passing the value returned from a call to getpid(2) will set the attribute for the main thread of the thread group. (If you are using the POSIX threads API, then use pthread_setaffinity_np(3) instead of sched_setaffinity().)
According to https://man7.org/linux/man-pages/man2/sched_getaffinity.2.html, which talks about threads, it's pretty clear from:
If pid is zero, then the mask of the calling thread is returned.
It doesn't sound like it would mean the same thing.
There was a problem hiding this comment.
@jdstrand, is sched_getaffinity restricted in process-id usage, too? i.e. would the usage above fall foul of the same situation that we have with sched_setaffinity that this PR aims to fix?
There was a problem hiding this comment.
It does not seem to be restricted, only sched_setaffinity is failing from my tests
There was a problem hiding this comment.
@jdstrand, is
sched_getaffinityrestricted in process-id usage, too? i.e. would the usage above fall foul of the same situation that we have withsched_setaffinitythat this PR aims to fix?
sched_getaffinity is allowed as part of the default template (since it doesn't allow interfering with other snaps and the small info leak isn't worth the developer friction of putting it in another interface).
…d, as a workaround for Snap (dotnet#40205) - Snap's default strict confinement doesn't allow setting the affinity of a different thread, and currently doesn't allow `sched_setaffinity(<nonzeroPid>, ...)`, which pthread implementation calls - Switched to use sched_setaffinity(0, ...) where appropriate Fix for dotnet#1634 in master
sched_setaffinity(<nonzeroPid>, ...)even with the calling thread's pid, which pthread implementation usessched_setaffinity(0, ...)where appropriateFix for #1634 in master