From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750942AbdE1P02 (ORCPT ); Sun, 28 May 2017 11:26:28 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:50723 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750846AbdE1P01 (ORCPT ); Sun, 28 May 2017 11:26:27 -0400 Subject: Re: mips qemu test failures in -next due to "kthread: Fix use-after-free if kthread fork fails" To: Vegard Nossum , Oleg Nesterov , Ralf Baechle Cc: Jamie Iles , Thomas Gleixner , linux-kernel@vger.kernel.org References: <20170527175612.GA22714@roeck-us.net> <1d1770a7-f1d7-d3ab-3522-92aaf1099171@oracle.com> From: Guenter Roeck Message-ID: <146635d2-08d9-e010-200e-ee774871cb93@roeck-us.net> Date: Sun, 28 May 2017 08:26:24 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <1d1770a7-f1d7-d3ab-3522-92aaf1099171@oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >