Linus Torvalds <[email protected]> writes:
On Wed, May 11, 2022 at 10:37 AM Eric W. Biederman
> <[email protected]> wrote:
>>
>> With the change to init and the user mode helper processes to not have
>> PF_KTHREAD set before they call kernel_execve the PF_KTHREAD test in
>> task_tick_numa became insufficient to detect all tasks that have
>> "->mm == NULL". Correct that by testing for "->mm == NULL" directly.
>
> If you end up rebasing at any time for other reasons (I didn't even
> check if you keep this series in a public git branch), please just
> fold this fix into the original commit, so that we don't have
> unnecessary bisection issues.
I do have it in a public git branch. The testing in linux-next
is what revealed this.
However it is a topic branch that as far as I know no one depends
on so I should be able to rebase it.
I can rearrange the patches and tweak the description a bit.
Say:
sched: Update task_tick_numa to ignore tasks without an mm
With the change to init and the user mode helper processes to not have
PF_KTHREAD set before they call kernel_execve the PF_KTHREAD test in
task_tick_numa became insufficient to detect all tasks that have
"->mm == NULL". Correct that by testing for "->mm == NULL" directly.
During testing Qian Cai <[email protected]> found this and wrote:
> Reverting the last 3 commits of the series fixed a boot crash.
>
> 1b2552cbdbe0 fork: Stop allowing kthreads to call execve
> 753550eb0ce1 fork: Explicitly set PF_KTHREAD
> 68d85f0a33b0 init: Deal with the init process being a user mode process
>
> BUG: KASAN: null-ptr-deref in task_nr_scan_windows.isra.0
> arch_atomic_long_read at ./include/linux/atomic/atomic-long.h:29
> (inlined by) atomic_long_read at ./include/linux/atomic/atomic-instrumented.h:1266
> (inlined by) get_mm_counter at ./include/linux/mm.h:1996
> (inlined by) get_mm_rss at ./include/linux/mm.h:2049
> (inlined by) task_nr_scan_windows at kernel/sched/fair.c:1123
> Read of size 8 at addr 00000000000003d0 by task swapper/0/1
Reported-by: Qian Cai <[email protected]>
Tested-by: Qian Cai <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: "Eric W. Biederman" <[email protected]>
Does that sound reasonable?
Eric
On Wed, May 11, 2022 at 10:53 AM Eric W. Biederman
<[email protected]> wrote:
>
> I do have it in a public git branch. The testing in linux-next
> is what revealed this.
>
> However it is a topic branch that as far as I know no one depends
> on so I should be able to rebase it.
Not a big deal, since it needs to not just bisect into that small
series, you also need a certain amount of bad luck to then hit the
issue.
So I don't think you should rebase unless you have other reasons to do
so, but if you do, just put this commit either first, or fold it into
the commit that removes PF_KTHREAD for threads that will become user
threads.
Linus