Re: mips qemu test failures in -next due to "kthread: Fix use-after-free if kthread fork fails"

[Guenter Roeck <linux@roeck-us.net>]

On 05/28/2017 07:49 AM, Vegard Nossum wrote:
> On 05/28/17 13:45, Vegard Nossum wrote:
>> On 05/27/17 19:56, Guenter Roeck wrote:
>>> Hi,
>>>
>>> my qemu testis of mips images are failing in -next. Symptom is a hang during
>>> boot; see http://kerneltests.org/builders/qemu-mips-next for some examples.
>>>
>>> I bisected the problem in next-20170526. It points to commit 4d6501dce079c
>>> ("kthread: Fix use-after-free if kthread fork fails"). Reverting that patch
>>> fixes the problem.
>>>
>>> Bisect log is attached.
>>
>> Hi,
>>
>> Thanks for the report and sorry for the breakage :-/
>>
>> I can't immediately spot what's going wrong, but I am able to reproduce
>> it on mips so I will try to debug.
>>
>> Are you sure it's this commit, though? I checked out linus/master and
>> I get a boot hang even after reverting it.
> 
> My mistake; I ran into a different bug which made me think it was
> hanging when it wasn't.
> 
> However, I think I found the problem; does this patch fix it for you too?
> 
> diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c
> index 918d4c73e951..5351e1f3950d 100644
> --- a/arch/mips/kernel/process.c
> +++ b/arch/mips/kernel/process.c
> @@ -120,7 +120,6 @@ int copy_thread_tls(unsigned long clone_flags, unsigned long usp,
>          struct thread_info *ti = task_thread_info(p);
>          struct pt_regs *childregs, *regs = current_pt_regs();
>          unsigned long childksp;
> -       p->set_child_tid = p->clear_child_tid = NULL;
> 
>          childksp = (unsigned long)task_stack_page(p) + THREAD_SIZE - 32;
> 

Confirmed; that patch fixes the problem for me.

Guenter

> The problem is that when we moved the p->{set,clear}_child_tid
> assignments inside copy_process(), the above assignments would clear
> them out. The assignments only exist on mips and openrisc (which would
> need the same patch), which explains why I didn't see it in my x86
> testing. I think the patch above should be safe given that we're now
> always setting these fields in copy_process() at an appropriate moment.
> 
> Looks like those assignments came from commit 3c37026d43c47 ("NPTL,
> round one."); Ralf?
> 
> Oleg?
> 
> 
> Vegard
>