On 8/1/22 12:45, Will Deacon wrote:
On Mon, Aug 01, 2022 at 11:41:23AM -0400, Waiman Long wrote:
The user_cpus_ptr field is added by commit b90ca8badbd1 ("sched:
Introduce task_struct::user_cpus_ptr to track requested affinity"). It
is currently used only by arm64 arch due to possible asymmetric cpu
setup. This patch extends its usage to save user provided cpumask when
sched_setaffinity() is called for all arches.
To preserve the existing arm64 use case, a new cpus_affinity_set flag is
added to differentiate if user_cpus_ptr is set up by sched_setaffinity()
or by force_compatible_cpus_allowed_ptr(). user_cpus_ptr
set by sched_setaffinity() has priority and won't be
overwritten by force_compatible_cpus_allowed_ptr() or
relax_compatible_cpus_allowed_ptr().
As a call to sched_setaffinity() will no longer clear user_cpus_ptr
but set it instead, the SCA_USER flag is no longer necessary and can
be removed.
Signed-off-by: Waiman Long <longman@xxxxxxxxxx>
---
include/linux/sched.h | 1 +
kernel/sched/core.c | 71 +++++++++++++++++++++++++++++++------------
kernel/sched/sched.h | 1 -
3 files changed, 52 insertions(+), 21 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index c46f3a63b758..60ae022fa842 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -815,6 +815,7 @@ struct task_struct {
unsigned int policy;
int nr_cpus_allowed;
+ int cpus_affinity_set;
const cpumask_t *cpus_ptr;
cpumask_t *user_cpus_ptr;
cpumask_t cpus_mask;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index da0bf6fe9ecd..7757828c7422 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2607,6 +2607,7 @@ int dup_user_cpus_ptr(struct task_struct *dst, struct task_struct *src,
return -ENOMEM;
cpumask_copy(dst->user_cpus_ptr, src->user_cpus_ptr);
+ dst->cpus_affinity_set = src->cpus_affinity_set;
I haven't been through this thorougly, but it looks a bit suspicious to me
to inherit this field directly across fork(). If a 64-bit task with this
flag set forks and then exec's a 32-bit program, arm64 will be in trouble if
we're not able to override the affinity forcefully.
I believe you can still override the affinity. What is in user_cpus_ptr
is not the actual affinity which is in cpus_mask. It is just what the
users desire. Its value has be masked off by the current cpuset as well
as what is allowed in task_cpu_possible_mask().
Cheers,
Longman
