Re: [PATCH 1/1] sched: fix user_mask double free

From: Waiman Long
Date: Tue Nov 22 2022 - 10:40:28 EST



On 11/22/22 09:05, Peter Zijlstra wrote:
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>

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.
(even just inserting some whitespace would've made it so much easier to
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.

With the latest change, user_cpus_ptr, once set, will not be cleared until when the task dies. That is why I don't recheck if user_cpus_ptr is NULL under pi_lock. The user_cpus_ptr value can certainly changes during its lifetime, but it will be stable under pi_lock. clear_user_cpus_ptr() is called by release_user_cpus_ptr() only. As said before, it is only call when the task dies at free_task() and so there shouldn't be any other racing conditions that can happen at the same time.

David, can you try the latest tip tree to see if the problem is still reproducible ?

Thanks,
Longman