lkml.org 
[lkml]   [2008]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2008-06-17 14:27    [W:0.068 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site