Re: [BUG: NULL pointer dereference] cgroupsand RT scheduling interact badly.

[Peter Zijlstra]

On Tue, 2008-06-17 at 14:25 +0200, Daniel K. wrote:
> 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.

Fun, I could not reproduce with chrt, but I can with schedtool.

Thanks for testing,. and I guess I'm back to poking at it.. :-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/