[compiler-rt] Relax pthread_getaffinity test to account for cgroups/docker

[DavidSpickett]

Summary

Fixes #58283

When running in a docker container you can have fewer cores assigned
to you than get_nrpoc would suggest.

Since the test just wants to know that interception worked, allow
any result > 0 and <= the global core count.

[DavidSpickett]

For https://github.com/llvm/llvm-project/issues/58283

Does this seem reasonable?

Perhaps there is a way to call the real pthread_getaffinity_np in the test instead, but I wasn't sure how that would be done.

[MaskRay]

I wonder whether we should just relax the test, instead of introducing a lit feature based on if os.cpu_count() != len(os.sched_getaffinity(0)).

I can confirm that the test also fails if I restrict affinity with something like numactl -C 0-3 /tmp/RelA/bin/llvm-lit -a /tmp/RelA/projects/compiler-rt/test/sanitizer_common/asan-x86_64-Linux/Linux/pthread_getaffinity_np.cpp

[vitalybuka]

compiler-rt/test/sanitizer_common/TestCases/Linux/pthread_getaffinity_np.cpp

14

Relaxing the test looks better to me

[DavidSpickett]

compiler-rt/test/sanitizer_common/TestCases/Linux/pthread_getaffinity_np.cpp

14

What does relaxing it look like?

I admit I don't have the context for all this test is trying to assert. My guess was that it's checking that the interception of pthread_getaffinity_np has been done correctly.

Relaxing it would mean simply calling it and expecting it to return something reasonable? Perhaps >0 and < get_nprocs()?

I wouldn't want to end up with a test that didn't test anything.

[vitalybuka]

compiler-rt/test/sanitizer_common/TestCases/Linux/pthread_getaffinity_np.cpp

14

Interceptors do some sanitizer specific checking, then forward the call to the real function, then do more sanitizer specific stuff.
Some interceptors are more complex and replace some logic of the default libc implementation

pthread_getaffinity_np is trivial interceptor, it just makes sanitizer know that cpu_set_t is going to be written. So we wan't to test that it does not crash, return some reasonable result, and, as in this case, output parameter filled with data or accessible.

E.g test will catch if we fail to intercept, the Msan will complain that CPU_COUNT_S is using uninitialized data from cpu_set_t.
We are not trying to validate behavior of pthread_getaffinity_np deep.

So here ">0 && <=nprocs" is reasonable fix.

[DavidSpickett]

compiler-rt/test/sanitizer_common/TestCases/Linux/pthread_getaffinity_np.cpp

14

Thanks for the explanation, I'll update this change then.

[DavidSpickett]

Relax the test condition instead of disabling it.

[MaskRay]

LGTM.

compiler-rt/test/sanitizer_common/TestCases/Linux/pthread_getaffinity_np.cpp

20

delete parentheses

compiler-rt/test/sanitizer_common/TestCases/Linux/pthread_getaffinity_np.cpp

 // RUN: %clangxx -O0 %s -o %t && %run %t
 
 // Android does not implement pthread_getaffinity_np.
 // (Note: libresolv is integrated with libc, but apparently only
 // sched_getaffinity).
 // UNSUPPORTED: android
 
 #include <assert.h>
 #include <pthread.h>
 #include <sys/sysinfo.h>
 
 #include <sanitizer/msan_interface.h>
 
 int main() {
   cpu_set_t set_x[4];
   pthread_t tid = pthread_self();
   int res = pthread_getaffinity_np(tid, sizeof(set_x), set_x);
   assert(res == 0);
-  assert(CPU_COUNT_S(sizeof(set_x), set_x) == get_nprocs());
+  int cpus = CPU_COUNT_S(sizeof(set_x), set_x);
+  assert(cpus > 0 && cpus <= get_nprocs());
 
   return 0;
 }