So you failed:
- to Cc the original author of this code (Will Deacon)
- to report what version this is against (apparently Linus' tree)
- to check if this still applies to the latest tree (it doesn't)
- to Cc the author of the code it now conflicts with (Waiman)
- write something coherent in the changelog.
- to include a Fixes tag.
Still, let me try and make sense of things...
On Mon, Nov 21, 2022 at 06:04:20PM +0800, wangbiao3@xxxxxxxxxx wrote:
From: wangbiao3 <wangbiao3@xxxxxxxxxx>(even just inserting some whitespace would've made it so much easier to
Clone/Fork a new task,call dup_task_struct->arch_dup_task_struct(tsk,orig)
which copy the data of parent/sibling task inclding p->user_cpus_ptr,so
the user_cpus_ptr of newtask is the same with orig task's.When
dup_task_struct call dup_user_cpus_ptr(tsk, orig, node),it return 0
dircetly if src->user_cpus_ptris free by other task,in this case ,
the newtask's address of user_cpus_ptr is not changed.
read)
But, the only way that would be possible is if
force_compatible_cpus_allowed_ptr() were to be called on !current, and
that just doesn't happen, the only callsite is:
arch/arm64/kernel/process.c: force_compatible_cpus_allowed_ptr(current);
And you can't be in fork() and exec() at the same time.
If it were possible to call restrict_cpus_allowed_ptr() on a non-current
task then yes, absolutely, which is why:
8f9ea86fdf99 ("sched: Always preserve the user requested cpumask")
also wraps the thing in pi_lock, but looking at it now, perhaps it needs
to do the alloc/copy first and swap under pi_lock instead.