[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160105163535.GD15594@dhcp22.suse.cz>
Date: Tue, 5 Jan 2016 17:35:36 +0100
From: Michal Hocko <mhocko@...nel.org>
To: Dave Jones <davej@...emonkey.org.uk>
Cc: Linux Kernel <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
David Rientjes <rientjes@...gle.com>
Subject: Re: [4.4-rc7] spinlock recursion while oom'ing.
[CCing David]
On Sun 03-01-16 17:27:28, Dave Jones wrote:
> This is an odd one..
>
> Out of memory: Kill process 5861 (trinity-c10) score 504 or sacrifice child
> BUG: spinlock recursion on CPU#1, trinity-c8/8828
> lock: 0xffff8800a3635410, .magic: dead4ead, .owner: trinity-c8/8828, .owner_cpu: 1
> CPU: 1 PID: 8828 Comm: trinity-c8 Not tainted 4.4.0-rc7-gelk-debug+ #3
> 00000000000001f8 ffff8800968d7808 ffffffff9a4d4451 ffff8800a3635410
> ffff8800968d7838 ffffffff9a117b36 ffff8800a3635410 ffff8800a3635420
> ffff8800a3635410 ffff8800a3635398 ffff8800968d7870 ffffffff9a117d63
> Call Trace:
> [<ffffffff9a4d4451>] dump_stack+0x4e/0x7d
> [<ffffffff9a117b36>] spin_dump+0xc6/0x130
> [<ffffffff9a117d63>] do_raw_spin_lock+0x163/0x1a0
> [<ffffffff9aae15ef>] _raw_spin_lock+0x1f/0x30
> [<ffffffff9a2271cb>] find_lock_task_mm+0x5b/0xd0
> [<ffffffff9a227cc0>] oom_kill_process+0x2a0/0x660
> [<ffffffff9a22855d>] out_of_memory+0x45d/0x4b0
Hmm, this is indeed weird. We are certainly not holding task_lock during
the allocation AFAICS (if yes that would be a GFP_KERNEL allocation with
a spinlock so I would assume a blow up earlier than when entering OOM).
oom_badness unlocks in all paths AFAICS. oom_kill_process will lock the
victim again but it releases the lock as well. dump_tasks the same.
> [<ffffffff9a228100>] ? check_panic_on_oom+0x80/0x80
> [<ffffffff9a22f4af>] ? __alloc_pages_direct_compact+0x7f/0x160
> [<ffffffff9a2302d0>] __alloc_pages_nodemask+0xd40/0xe80
> [<ffffffff9a0a2ae9>] ? copy_process+0x1d9/0x2ab0
> [<ffffffff9a22f590>] ? __alloc_pages_direct_compact+0x160/0x160
> [<ffffffff9a294700>] ? print_section+0x50/0x60
> [<ffffffff9a0deff1>] ? preempt_count_sub+0xc1/0x120
> [<ffffffff9aada916>] ? preempt_schedule_irq+0x86/0xb0
> [<ffffffff9aae28bd>] ? retint_kernel+0x1b/0x1d
> [<ffffffff9a2973f3>] ? deactivate_slab+0x3a3/0x400
> [<ffffffff9aae1758>] ? _raw_spin_unlock+0x18/0x30
> [<ffffffff9a297be5>] ? __slab_alloc.isra.62.constprop.64+0x45/0x50
> [<ffffffff9a29c00e>] ? kasan_kmalloc+0x5e/0x70
> [<ffffffff9a29c2ed>] ? kasan_slab_alloc+0xd/0x10
> [<ffffffff9a297ce1>] ? kmem_cache_alloc+0xf1/0x200
> [<ffffffff9a230505>] alloc_kmem_pages_node+0x25/0x30
> [<ffffffff9a0a2b07>] copy_process+0x1f7/0x2ab0
> [<ffffffff9a0def4a>] ? preempt_count_sub+0x1a/0x120
> [<ffffffff9aae1758>] ? _raw_spin_unlock+0x18/0x30
> [<ffffffff9a4f0d32>] ? iov_iter_init+0x82/0xc0
> [<ffffffff9a141d82>] ? jiffies_to_timeval+0x52/0x70
> [<ffffffff9a1ab530>] ? taskstats_exit+0x5a0/0x5a0
> [<ffffffff9a0f1b4f>] ? sched_clock_local+0x3f/0xb0
> [<ffffffff9a0a2910>] ? __cleanup_sighand+0x30/0x30
> [<ffffffff9a1abf40>] ? acct_account_cputime+0x40/0x50
> [<ffffffff9a0deff1>] ? preempt_count_sub+0xc1/0x120
> [<ffffffff9a0a5637>] _do_fork+0x107/0x510
> [<ffffffff9a0a5530>] ? fork_idle+0x130/0x130
> [<ffffffff9a002f20>] ? enter_from_user_mode+0x50/0x50
> [<ffffffff9a501f43>] ? __this_cpu_preempt_check+0x13/0x20
> [<ffffffff9a21ebc5>] ? __context_tracking_enter+0x95/0x140
> [<ffffffff9a1e2f20>] ? syscall_exit_register+0x310/0x310
> [<ffffffff9a0a5ae9>] SyS_clone+0x19/0x20
> [<ffffffff9aae1ef9>] tracesys_phase2+0x84/0x89
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists