Skip to content

sched/core: Use empty mask to reset cpumasks in sched_setaffinity()

Waiman Long requested to merge llong1/centos-stream-9:bz2219681_setaffinity into main

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2219681
Upstream Status: RHEL only

Since commit 8f9ea86fdf99 ("sched: Always preserve the user requested cpumask"), user provided CPU affinity via sched_setaffinity(2) is perserved even if the task is being moved to a different cpuset. However, that affinity is also being inherited by any subsequently created child processes which may not want or be aware of that affinity.

One way to solve this problem is to provide a way to back off from that user provided CPU affinity. This patch implements such a scheme by using an empty cpumask to signal a reset of the cpumasks to the default as allowed by the current cpuset.

Before this patch, passing in an empty cpumask to sched_setaffinity(2) will always return an -EINVAL error. With this patch, an alternative error of -ENODEV will be returned returned if sched_setaffinity(2) has been called before to set up user_cpus_ptr. In this case, the user_cpus_ptr that stores the user provided affinity will be cleared and the task's CPU affinity will be reset to that of the current cpuset. This alternative error code of -ENODEV signals that the no CPU is specified and, at the same time, a side effect of resetting cpu affinity to the cpuset default.

If sched_setaffinity(2) has not been called previously, an EINVAL error will be returned with an empty cpumask just like before. Tests or tools that rely on the behavior that an empty cpumask will return an error code will not be affected.

Signed-off-by: Waiman Long longman@redhat.com

Edited by Waiman Long

Merge request reports