Re: [PATCH] pidmap: Use GFP_ATOMIC to allocate page (was: Re: [00/54] 3.0.32-stable review)

[David Rientjes]

On Sat, 19 May 2012, Steven Rostedt wrote:

> Ran 18 tests against 3.0.32-rc, 2 failed (16 passed!). One failed by a
> lock up (still looking into it) and the other is this one:
> 
> Calibrating delay loop (skipped), value calculated using timer frequency.. 4799.59 BogoMIPS (lpj=2399799)
> pid_max: default: 32768 minimum: 301
> BUG: scheduling while atomic: swapper/0/0x10000002
> Modules linked in:
> Pid: 0, comm: swapper Not tainted 3.1.0-rc9-test+ #1
> Call Trace:
>  [<ffffffff81435b3e>] __schedule_bug+0x57/0x5b
>  [<ffffffff8143c44f>] __schedule+0x90/0x672
>  [<ffffffff810636dd>] ? kzalloc.constprop.2+0x24/0x26
>  [<ffffffff810460d1>] __cond_resched+0x23/0x2f
>  [<ffffffff8143ca83>] _cond_resched+0x14/0x1d^M
>  [<ffffffff810f7cd3>] slab_pre_alloc_hook.isra.52+0x28/0x2c
>  [<ffffffff810f8b1a>] kmem_cache_alloc_trace+0x29/0xbd
>  [<ffffffff810636dd>] kzalloc.constprop.2+0x24/0x26
>  [<ffffffff81b7a434>] pidmap_init+0x81/0xc0
>  [<ffffffff81b61b03>] start_kernel+0x330/0x3c2
>  [<ffffffff81b612c4>] x86_64_start_reservations+0xaf/0xb3
>  [<ffffffff81b61140>] ? early_idt_handlers+0x140/0x140
>  [<ffffffff81b613ca>] x86_64_start_kernel+0x102/0x111
> Security Framework initialized
> 
> Had CONFIG_SLUB, IRQ_FORCED_THREADING and voluntary preempt enabled.
> Seems the might_resched() check from might_sleep_if() in
> pre_alloc_hook() caused a schedule in early boot (pidmap_init). Not sure
> why it scheduled that early, perhaps a threaded interrupt was added? I
> haven't been able to reproduce it again.
> 
> Perhaps we should not be using GFP_KERNEL when allocating memory for
> pidmap_init()? As we have preemption disabled at this point, we should
> be using GFP_ATOMIC. Also add a BUG_ON if the page fails to get
> allocated.
> 
> Signed-off-by: Steven Rostedt <rostedt@xxxxxxxxxxx>
> 
> This patch is against 3.4-rc2 (just happened to be a kernel checkout I
> had).
> 
> diff --git a/kernel/pid.c b/kernel/pid.c
> index 9f08dfa..32dab20 100644
> --- a/kernel/pid.c
> +++ b/kernel/pid.c
> @@ -563,7 +563,9 @@ void __init pidmap_init(void)
>  				PIDS_PER_CPU_MIN * num_possible_cpus());
>  	pr_info("pid_max: default: %u minimum: %u\n", pid_max, pid_max_min);
>  
> -	init_pid_ns.pidmap[0].page = kzalloc(PAGE_SIZE, GFP_KERNEL);
> +	/* Preemption is still disabled at this point */
> +	init_pid_ns.pidmap[0].page = kzalloc(PAGE_SIZE, GFP_ATOMIC);
> +	BUG_ON(!init_pid_ns.pidmap[0].page);
>  	/* Reserve PID 0. We never call free_pidmap(0) */
>  	set_bit(0, init_pid_ns.pidmap[0].page);
>  	atomic_dec(&init_pid_ns.pidmap[0].nr_free);

Why wasn't this caught by gfp_allowed_mask in slab_pre_alloc_hook()?  
GFP_KERNEL should be allowed in this context.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/