cpuset: Fix sched_[g|s]etaffinity() for better compatibility with Linux.

[dchagin]

Summary

Under Linux to sched_[g|s]etaffinity() functions the value returned from a call
to gettid(2) (thread id) 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) (process id) will set the attribute for the main thread
of the thread group.

Native cpuset(2) family of system calls has "which" argument to determine how
the value of id argument is interpreted, i.e., CPU_WHICH_TID is used to pass
a thread id and CPU_WHICH_PID - to pass a process id.

For now native sched_[g|s]etaffinity() implementation is wrong as uses "which"
CPU_WHICH_PID to pass both (process and thread id) to the kernel. To fix this
adding a new "which" CPU_WHICH_TIDORPID intended to handle both id's.

[kib]

sys/kern/kern_cpuset.c

2154

I do not see a need of this if statement for CPU_WHICH_PID. IMO duplicating cpuset_setproc() line is not too much duplication for simplifying the if() condition. You can remove CPU_WHICH_TID from the check.

Same for the other cases.

sys/sys/cpuset.h

118

[dchagin]

thanks, fixed, looks better )

[kib]

sys/kern/kern_cpuset.c

1756

1990–1991

So this changes semantic for CPU_WHICH_TID, making it to accept pid and return OR of all threads' cpuset masks.

Is it intended? Is it needed?

2156

Again, this makes CPU_WHICH _TID accept pid.

[dchagin]

sys/kern/kern_cpuset.c

1990–1991

well, I dont think so, the cpuset_which() above do not permit such cases, i.e., specify pid for CPU_WHICH_TID and vice versa. However, to avoid confusing, I will redo this.

[dchagin]

fixed

[kib]

The cpuset(2) should be updated with CPU_WHICH_TIDPID

[dchagin]

Well, I wasn't planning adding the new which to the manual as
handling of it is incomplete. Below is an attempt to handle new which.
Compile tested

[kib]

lib/libc/sys/cpuset.2

103 ↗

(On Diff #115987)

[dchagin]

cpuset.2 fixed