Messages in this thread | | | Date | Tue, 3 Oct 2023 11:17:58 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH v3] sched/core: Use empty mask to reset cpumasks in sched_setaffinity() |
| |
* Waiman Long <longman@redhat.com> wrote:
> 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.
I agree that this problem needs a solution, but I don't really agree with the -ENODEV ABI hack.
Why not just return success in that case? The 'reset' of the mask was successful after all.
Thanks,
Ingo
| |