Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755562AbdLVDfE (ORCPT ); Thu, 21 Dec 2017 22:35:04 -0500 Received: from scorn.kernelslacker.org ([45.56.101.199]:59154 "EHLO scorn.kernelslacker.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752766AbdLVDfD (ORCPT ); Thu, 21 Dec 2017 22:35:03 -0500 Date: Thu, 21 Dec 2017 22:35:00 -0500 From: Dave Jones To: "Eric W. Biederman" Cc: Alexey Dobriyan , Linus Torvalds , Al Viro , Linux Kernel , syzkaller-bugs@googlegroups.com, Gargi Sharma , Oleg Nesterov , Rik van Riel , Andrew Morton Subject: Re: proc_flush_task oops Message-ID: <20171222033500.GA17273@codemonkey.org.uk> Mail-Followup-To: Dave Jones , "Eric W. Biederman" , Alexey Dobriyan , Linus Torvalds , Al Viro , Linux Kernel , syzkaller-bugs@googlegroups.com, Gargi Sharma , Oleg Nesterov , Rik van Riel , Andrew Morton References: <20171219193020.GA9237@codemonkey.org.uk> <878tdy5r5t.fsf@xmission.com> <87mv2e17vz.fsf@xmission.com> <20171220052803.GA17079@codemonkey.org.uk> <871sjp1cjz.fsf@xmission.com> <20171221031606.GA4636@codemonkey.org.uk> <87po78trjm.fsf@xmission.com> <20171221220044.GA4977@codemonkey.org.uk> <87wp1fk0pd.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wp1fk0pd.fsf@xmission.com> User-Agent: Mutt/1.9.2 (2017-12-15) X-Spam-Note: SpamAssassin invocation failed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1390 Lines: 36 On Thu, Dec 21, 2017 at 07:31:26PM -0600, Eric W. Biederman wrote: > Dave Jones writes: > > > On Thu, Dec 21, 2017 at 12:38:12PM +0200, Alexey Dobriyan wrote: > > > > > > with proc_mnt still set to NULL is a mystery to me. > > > > > > > > Is there any chance the idr code doesn't always return the lowest valid > > > > free number? So init gets assigned something other than 1? > > > > > > Well, this theory is easy to test (attached). > > > > I didn't hit this BUG, but I hit the same oops in proc_flush_task. > > Scratch one idea. > > If it isn't too much trouble can you try this. > > I am wondering if somehow the proc_mnt that is NULL is somewhere in the > middle of the stack of pid namespaces. > > This adds two warnings. The first just reports which pid namespace in > the stack of pid namespaces is problematic, and the pid number in that > pid namespace. Which should give a whole lot more to go by. > > The second warning complains if we manage to create a pid namespace > where the parent pid namespace is not properly set up. The test to > prevent that looks quite robust, but at this point I don't know where to > look. Progress ? [ 1653.030190] ------------[ cut here ]------------ [ 1653.030852] 1/1: 2 no proc_mnt [ 1653.030946] WARNING: CPU: 2 PID: 4420 at kernel/pid.c:213 alloc_pid+0x24f/0x2a0