Re: [linux-next PATCH] sched: cgroup: enable interrupt before calling threadgroup_change_begin
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: [] release_freepages+0x18/0xa0 PGD 0 Oops: [#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: 880361732680 ti: 88036173c000 task.ti: 88036173c000 RIP: 0010:[] [] release_freepages+0x18/0xa0 RSP: 0018:88036173fcf8 EFLAGS: 00010282 RAX: RBX: 88036ffde7c0 RCX: 0009 RDX: 1bf1 RSI: 000f RDI: 88036173fdd0 RBP: 88036173fd20 R08: 0007 R09: 1600 R10: 88036ffde7c0 R11: R12: R13: 88036173fdd0 R14: 88036173fdc0 R15: 88036173fdb0 FS: () GS:880363cc() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 02206000 CR4: 06e0 Stack: 88036ffde7c0 1a00 88036173fdc0 88036173fdb0 88036173fda0 8119f13d 81196239 880361732680 0001 0010 Call Trace: [] compact_zone+0x55d/0x9f0 [] ? fragmentation_index+0x19/0x70 [] kcompactd_do_work+0x10f/0x230 [] kcompactd+0x90/0x1e0 [] ? wait_woken+0xa0/0xa0 [] ? kcompactd_do_work+0x230/0x230 [] kthread+0xdd/0x100 [] ret_from_fork+0x22/0x40 [] ? 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 [] release_freepages+0x18/0xa0 RSP CR2: ---[ 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
Re: [linux-next PATCH] sched: cgroup: enable interrupt before calling threadgroup_change_begin
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: [] release_freepages+0x18/0xa0 PGD 0 Oops: [#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: 880361732680 ti: 88036173c000 task.ti: 88036173c000 RIP: 0010:[] [] release_freepages+0x18/0xa0 RSP: 0018:88036173fcf8 EFLAGS: 00010282 RAX: RBX: 88036ffde7c0 RCX: 0009 RDX: 1bf1 RSI: 000f RDI: 88036173fdd0 RBP: 88036173fd20 R08: 0007 R09: 1600 R10: 88036ffde7c0 R11: R12: R13: 88036173fdd0 R14: 88036173fdc0 R15: 88036173fdb0 FS: () GS:880363cc() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: CR3: 02206000 CR4: 06e0 Stack: 88036ffde7c0 1a00 88036173fdc0 88036173fdb0 88036173fda0 8119f13d 81196239 880361732680 0001 0010 Call Trace: [] compact_zone+0x55d/0x9f0 [] ? fragmentation_index+0x19/0x70 [] kcompactd_do_work+0x10f/0x230 [] kcompactd+0x90/0x1e0 [] ? wait_woken+0xa0/0xa0 [] ? kcompactd_do_work+0x230/0x230 [] kthread+0xdd/0x100 [] ret_from_fork+0x22/0x40 [] ? 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 [] release_freepages+0x18/0xa0 RSP CR2: ---[ 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
Re: [linux-next PATCH] sched: cgroup: enable interrupt before calling threadgroup_change_begin
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.
[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 88036173f9e8 8152666f 880361732680 88036173fa08 81088b13 81ee3372 0b2a 88036173fa30 81088bd9 880361732680 Call Trace: [] dump_stack+0x67/0x98 [] ___might_sleep+0x123/0x1a0 [] __might_sleep+0x49/0x80 [] exit_signals+0x24/0x130 [] do_exit+0xc4/0xca0 [] oops_end+0x89/0xc0 [] no_context+0x144/0x390 [] ? debug_smp_processor_id+0x17/0x20 [] __bad_area_nosemaphore+0x10d/0x230 [] ? free_hot_cold_page_list+0x49/0xd0 [] bad_area_nosemaphore+0x14/0x20 [] __do_page_fault+0x237/0x570 [] do_page_fault+0x29/0x80 [] page_fault+0x22/0x30 [] ? release_freepages+0x18/0xa0 [] compact_zone+0x55d/0x9f0 [] ? fragmentation_index+0x19/0x70 [] kcompactd_do_work+0x10f/0x230 [] kcompactd+0x90/0x1e0 [] ? wait_woken+0xa0/0xa0 [] ? kcompactd_do_work+0x230/0x230 [] kthread+0xdd/0x100 [] ret_from_fork+0x22/0x40 [] ? 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 --- 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. */ -- 2.0.2
