linux-kernel - Re: [BUG: NULL pointer dereference] cgroups and RT scheduling interact badly.

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]

Message-ID: <4857AD38.2090601@uw.no>
Date:	Tue, 17 Jun 2008 14:25:28 +0200
From:	"Daniel K." <dk@...no>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	mingo@...e.hu, menage@...gle.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>
Subject: Re: [BUG: NULL pointer dereference] cgroups and	RT	scheduling	interact
 badly.

Peter Zijlstra wrote:
> How's this [patch] work for you? (includes the previuos patchlet too)

Thanks,

this patch fixed the obvious problem, namely

# echo $$ > /dev/cgroup/burn/oops/tasks
# schedtool -R -p 1 -e burnP6 &

now works again. However, the last step below

# echo $$ > /dev/cgroup/tasks
# burnP6 &
[1] 3414
# echo 3414 > /dev/cgroup/burn/oops/tasks
# schedtool -R -p 1 3414

gives this new and shiny Oops instead.

> [  189.274997] BUG: unable to handle kernel NULL pointer dereference at 0000000000000064
> [  189.274997] IP: [<ffffffff8022e165>] __enqueue_rt_entity+0x55/0x1d0
> [  189.274997] PGD 21e451067 PUD 220d19067 PMD 0 
> [  189.274997] Oops: 0002 [1] SMP 
> [  189.274997] CPU 1 
> [  189.274997] Modules linked in: netconsole configfs ipmi_msghandler kvm_amd kvm ipv6 iptable_filter ip_tables x_tables af_packet loop evdev usbhid hid i2c_nforce2 button pcspkr i2c_core k8temp shpchp pci_hotplug tg3 sd_mod forcedeth sg ohci_hcd ehci_hcd usbcore thermal processor fan
> [  189.274997] Pid: 3415, comm: schedtool Not tainted 2.6.26-rc6 #3
> [  189.274997] RIP: 0010:[<ffffffff8022e165>]  [<ffffffff8022e165>] __enqueue_rt_entity+0x55/0x1d0
> [  189.274997] RSP: 0018:ffff81021e477e48  EFLAGS: 00010012
> [  189.274997] RAX: ffff810001056d08 RBX: ffff810220dbc060 RCX: ffff810220dbbfc0
> [  189.274997] RDX: 0000000000000064 RSI: ffff81022120ec60 RDI: ffff810220dbc060
> [  189.274997] RBP: ffff81021e477e58 R08: 44b0000000000000 R09: 0000000000000001
> [  189.274997] R10: 0000000000000000 R11: 0000000000000206 R12: ffff8100010566b8
> [  189.274997] R13: 0000000000000001 R14: 0000000000000001 R15: ffff81021e477f38
> [  189.274997] FS:  00007f71ec2146e0(0000) GS:ffff810223022580(0000) knlGS:0000000000000000
> [  189.274997] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [  189.274997] CR2: 0000000000000064 CR3: 000000021e439000 CR4: 00000000000006e0
> [  189.274997] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [  189.274997] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [  189.274997] Process schedtool (pid: 3415, threadinfo ffff81021e476000, task ffff810221daf920)
> [  189.274997] Stack:  ffff810220dbc060 ffff81022120ec60 ffff81021e477e78 ffffffff8022e34e
> [  189.274997]  0000000000000001 ffff81022120ec60 ffff81021e477e98 ffffffff802299e3
> [  189.274997]  ffff81021e477f38 ffff8100010565c0 ffff81021e477eb8 ffffffff80229a60
> [  189.274997] Call Trace:
> [  189.274997]  [<ffffffff8022e34e>] enqueue_rt_entity+0x1e/0x30
> [  189.274997]  [<ffffffff802299e3>] enqueue_task+0x13/0x30
> [  189.274998]  [<ffffffff80229a60>] activate_task+0x30/0x50
> [  189.274998]  [<ffffffff80232ebf>] sched_setscheduler+0x28f/0x3b0
> [  189.274998]  [<ffffffff8028b368>] ? do_munmap+0x278/0x2d0
> [  189.274998]  [<ffffffff8023305d>] do_sched_setscheduler+0x7d/0x90
> [  189.274998]  [<ffffffff802330a4>] sys_sched_setscheduler+0x14/0x20
> [  189.274998]  [<ffffffff8020b77a>] system_call_after_swapgs+0x8a/0x8f
> [  189.274998] 
> [  189.274998] 
> [  189.274998] Code: 85 c9 0f 84 76 01 00 00 8b 81 58 06 00 00 48 98 48 8d 8b 60 ff ff ff 48 c1 e0 04 4a 8d 44 20 10 48 8b 50 08 48 89 03 48 89 58 08 <48> 89 1a 48 89 53 08 48 8b 53 40 48 8d 82 58 06 00 00 48 85 d2 
> [  189.274998] RIP  [<ffffffff8022e165>] __enqueue_rt_entity+0x55/0x1d0
> [  189.274998]  RSP <ffff81021e477e48>
> [  189.274998] CR2: 0000000000000064

If I switch the order of calling schedtool and assigning the task to a
cgroup, then it works OK.

# echo $$ > /dev/cgroup/tasks
# burnP6 &
[1] 3414
# schedtool -R -p 1 3414
# echo 3414 > /dev/cgroup/burn/oops/tasks

Note the distinct lack of an Oops here.

But all is not well. If I now use schedtool (obvoiusly redundantly)

# schedtool -R -p 1 3414

I get a new Oops, which looks essentially tha same as the one above.


Daniel K.
--
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/