On Thu, Dec 21, 2017 at 07:31:26PM -0600, Eric W. Biederman wrote: > Dave Jones <da...@codemonkey.org.uk> 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
