linux-kernel - Re: [linux-next PATCH] sched: cgroup: enable interrupt before calling threadgroup_change

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Apr 2016 10:35:45 -0700
From:	"Shi, Yang" <yang.shi@...aro.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	tj@...nel.org, mingo@...hat.com, lizefan@...wei.com,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
	linaro-kernel@...ts.linaro.org
Subject: 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: [<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

>