[linux-next PATCH] sched: cgroup: enable interrupt before calling threadgroup_change_begin
When kernel oops happens in some kernel thread, i.e. kcompactd in the test, the below bug might be triggered by the oops handler:
BUG: sleeping function called from invalid context at include/linux/sched.h:2858 in_atomic(): 0, irqs_disabled(): 1, pid: 110, name: kcompactd0 CPU: 6 PID: 110 Comm: kcompactd0 Tainted: G D 4.6.0-rc4-next-20160420 #4 Hardware name: Intel Corporation S5520HC/S5520HC, BIOS S5500.86B.01.10.0025.030220091519 03/02/2009 0000000000000000 ffff88036173f9e8 ffffffff8152666f 0000000000000000 ffff880361732680 ffff88036173fa08 ffffffff81088b13 ffffffff81ee3372 0000000000000b2a ffff88036173fa30 ffffffff81088bd9 ffff880361732680 Call Trace: [<ffffffff8152666f>] dump_stack+0x67/0x98 [<ffffffff81088b13>] ___might_sleep+0x123/0x1a0 [<ffffffff81088bd9>] __might_sleep+0x49/0x80 [<ffffffff810706b4>] exit_signals+0x24/0x130 [<ffffffff81063cc4>] do_exit+0xc4/0xca0 [<ffffffff810201d9>] oops_end+0x89/0xc0 [<ffffffff810518c4>] no_context+0x144/0x390 [<ffffffff81542f17>] ? debug_smp_processor_id+0x17/0x20 [<ffffffff81051c1d>] __bad_area_nosemaphore+0x10d/0x230 [<ffffffff811769e9>] ? free_hot_cold_page_list+0x49/0xd0 [<ffffffff81051d54>] bad_area_nosemaphore+0x14/0x20 [<ffffffff81051f97>] __do_page_fault+0x237/0x570 [<ffffffff810522f9>] do_page_fault+0x29/0x80 [<ffffffff81be7b22>] page_fault+0x22/0x30 [<ffffffff8119d2f8>] ? release_freepages+0x18/0xa0 [<ffffffff8119f13d>] compact_zone+0x55d/0x9f0 [<ffffffff81196239>] ? fragmentation_index+0x19/0x70 [<ffffffff8119f92f>] kcompactd_do_work+0x10f/0x230 [<ffffffff8119fae0>] kcompactd+0x90/0x1e0 [<ffffffff810a3a40>] ? wait_woken+0xa0/0xa0 [<ffffffff8119fa50>] ? kcompactd_do_work+0x230/0x230 [<ffffffff810801ed>] kthread+0xdd/0x100 [<ffffffff81be5ee2>] ret_from_fork+0x22/0x40 [<ffffffff81080110>] ? kthread_create_on_node+0x180/0x180
Since the code path may be called in interrupt disabled context, so the might_sleep in threadgroup_change_begin() may be triggered.
Before calling exit_signals(), it already checked if it is in hard IRQ handler, so it sounds safe to reenable interrupt at that point.
Signed-off-by: Yang Shi yang.shi@linaro.org --- kernel/exit.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/kernel/exit.c b/kernel/exit.c index 9e6e135..c6f8e37 100644 --- a/kernel/exit.c +++ b/kernel/exit.c @@ -679,6 +679,14 @@ void do_exit(long code) validate_creds_for_do_exit(tsk);
/* + * It is possible to get here with interrupt disabled when fault + * happens in kernel thread. Enable interrupt to make threadgroup + * happy. + */ + if (irqs_disabled()) + local_irq_enable(); + + /* * We're taking recursive faults here in do_exit. Safest is to just * leave this task alone and wait for reboot. */
On 4/23/2016 2:14 AM, Peter Zijlstra wrote:
On Fri, Apr 22, 2016 at 08:56:28PM -0700, Yang Shi wrote:
When kernel oops happens in some kernel thread, i.e. kcompactd in the test, the below bug might be triggered by the oops handler:
What are you trying to fix? You already oopsed the thing is wrecked.
Actually, I ran into the below kernel BUG:
BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff8119d2f8>] release_freepages+0x18/0xa0 PGD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: CPU: 6 PID: 110 Comm: kcompactd0 Not tainted 4.6.0-rc4-next-20160420 #4 Hardware name: Intel Corporation S5520HC/S5520HC, BIOS S5500.86B.01.10.0025.030220091519 03/02/2009 task: ffff880361732680 ti: ffff88036173c000 task.ti: ffff88036173c000 RIP: 0010:[<ffffffff8119d2f8>] [<ffffffff8119d2f8>] release_freepages+0x18/0xa0 RSP: 0018:ffff88036173fcf8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff88036ffde7c0 RCX: 0000000000000009 RDX: 0000000000001bf1 RSI: 000000000000000f RDI: ffff88036173fdd0 RBP: ffff88036173fd20 R08: 0000000000000007 R09: 0000160000000000 R10: ffff88036ffde7c0 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88036173fdd0 R14: ffff88036173fdc0 R15: ffff88036173fdb0 FS: 0000000000000000(0000) GS:ffff880363cc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002206000 CR4: 00000000000006e0 Stack: ffff88036ffde7c0 0000000000000000 0000000000001a00 ffff88036173fdc0 ffff88036173fdb0 ffff88036173fda0 ffffffff8119f13d ffffffff81196239 0000000000000000 ffff880361732680 0000000000000001 0000000000100000 Call Trace: [<ffffffff8119f13d>] compact_zone+0x55d/0x9f0 [<ffffffff81196239>] ? fragmentation_index+0x19/0x70 [<ffffffff8119f92f>] kcompactd_do_work+0x10f/0x230 [<ffffffff8119fae0>] kcompactd+0x90/0x1e0 [<ffffffff810a3a40>] ? wait_woken+0xa0/0xa0 [<ffffffff8119fa50>] ? kcompactd_do_work+0x230/0x230 [<ffffffff810801ed>] kthread+0xdd/0x100 [<ffffffff81be5ee2>] ret_from_fork+0x22/0x40 [<ffffffff81080110>] ? kthread_create_on_node+0x180/0x180 Code: c1 fa 06 31 f6 e8 a9 9b fd ff eb 98 0f 1f 80 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 57 41 56 41 55 49 89 fd 41 54 53 48 8b 07 <48> 8b 10 48 8d 78 e0 49 39 c5 4c 8d 62 e0 74 70 49 be 00 00 00 RIP [<ffffffff8119d2f8>] release_freepages+0x18/0xa0 RSP <ffff88036173fcf8> CR2: 0000000000000000 ---[ end trace 2e96d09e0ba6342f ]---
Then the "schedule in atomic context" bug is triggered which cause the system hang. But, the system is still alive without the "schedule in atomic context" bug. The previous null pointer deference issue doesn't bring the system down other than killing the compactd kthread.
Thanks, Yang
On 4/25/2016 10:35 AM, Shi, Yang wrote:
On 4/23/2016 2:14 AM, Peter Zijlstra wrote:
On Fri, Apr 22, 2016 at 08:56:28PM -0700, Yang Shi wrote:
When kernel oops happens in some kernel thread, i.e. kcompactd in the test, the below bug might be triggered by the oops handler:
What are you trying to fix? You already oopsed the thing is wrecked.
Actually, I ran into the below kernel BUG:
BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff8119d2f8>] release_freepages+0x18/0xa0 PGD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: CPU: 6 PID: 110 Comm: kcompactd0 Not tainted 4.6.0-rc4-next-20160420 #4 Hardware name: Intel Corporation S5520HC/S5520HC, BIOS S5500.86B.01.10.0025.030220091519 03/02/2009 task: ffff880361732680 ti: ffff88036173c000 task.ti: ffff88036173c000 RIP: 0010:[<ffffffff8119d2f8>] [<ffffffff8119d2f8>] release_freepages+0x18/0xa0 RSP: 0018:ffff88036173fcf8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff88036ffde7c0 RCX: 0000000000000009 RDX: 0000000000001bf1 RSI: 000000000000000f RDI: ffff88036173fdd0 RBP: ffff88036173fd20 R08: 0000000000000007 R09: 0000160000000000 R10: ffff88036ffde7c0 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88036173fdd0 R14: ffff88036173fdc0 R15: ffff88036173fdb0 FS: 0000000000000000(0000) GS:ffff880363cc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002206000 CR4: 00000000000006e0 Stack: ffff88036ffde7c0 0000000000000000 0000000000001a00 ffff88036173fdc0 ffff88036173fdb0 ffff88036173fda0 ffffffff8119f13d ffffffff81196239 0000000000000000 ffff880361732680 0000000000000001 0000000000100000 Call Trace: [<ffffffff8119f13d>] compact_zone+0x55d/0x9f0 [<ffffffff81196239>] ? fragmentation_index+0x19/0x70 [<ffffffff8119f92f>] kcompactd_do_work+0x10f/0x230 [<ffffffff8119fae0>] kcompactd+0x90/0x1e0 [<ffffffff810a3a40>] ? wait_woken+0xa0/0xa0 [<ffffffff8119fa50>] ? kcompactd_do_work+0x230/0x230 [<ffffffff810801ed>] kthread+0xdd/0x100 [<ffffffff81be5ee2>] ret_from_fork+0x22/0x40 [<ffffffff81080110>] ? kthread_create_on_node+0x180/0x180 Code: c1 fa 06 31 f6 e8 a9 9b fd ff eb 98 0f 1f 80 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 57 41 56 41 55 49 89 fd 41 54 53 48 8b 07 <48> 8b 10 48 8d 78 e0 49 39 c5 4c 8d 62 e0 74 70 49 be 00 00 00 RIP [<ffffffff8119d2f8>] release_freepages+0x18/0xa0 RSP <ffff88036173fcf8> CR2: 0000000000000000 ---[ end trace 2e96d09e0ba6342f ]---
Then the "schedule in atomic context" bug is triggered which cause the system hang. But, the system is still alive without the "schedule in atomic context" bug. The previous null pointer deference issue doesn't bring the system down other than killing the compactd kthread.
BTW, I don't have "panic on oops" set. So, the kernel doesn't panic.
Thanks, Yang
Thanks, Yang
linaro-kernel@lists.linaro.org
-
Peter Zijlstra -
Shi, Yang -
Yang Shi