Comment 14 for bug 693594

Jon,

if you could do these soon in the Debian package, I think we should
still be able to get it into precise.

Rioting_Pacifst,

note that we generally recommend using cgroup-lite when possible.

Quoting Rioting_Pacifst (<email address hidden>):
> This bug has quite a few nasty symptoms (breaks suspend on SMP machines,
> etc) and I guess cgroups are going to get more popular as people try the
> "superpatch" so could we get one of the following into 12.04 please:
>
> 1)do not move all tasks into a default cgroup
> comment CREATE_DEFAULT=yes out and uncomment CREATE_DEFAULT=no in /etc/default/cgconfig
>
> 2)putting the following in /etc/cgconfig.conf
> group sysdefault {
> cpu {
> cpu.rt_runtime_us = 950000;
> }
> }
>
> 3) Add a rule so that [kthreadd] is never put in the default group
>
> 4) Changing startup script to not move ktreadadd
>
> I think creating a superflous default group is stupid anyway so the
> first fix is by far the best.
>
> Upstream have also release 0.38 but nothing in the changelog seems
> relevant.
>
> --
> You received this bug notification because you are subscribed to
> libcgroup in Ubuntu.
> https://bugs.launchpad.net/bugs/693594
>
> Title:
> cgroup-bin should not move kthreadd into a default cgroup
>
> Status in “libcgroup” package in Ubuntu:
> Confirmed
>
> Bug description:
> Steps to reproduce:
> 1. Install cgroup-bin from universe on a stock Lucid machine (I've only tested amd64, but I suspect it shouldn't matter)
> 2. Load an arbitrary module (e.g. modprobe rds)
> 3. Unload the module loaded in (2) (e.g. rmmod rds)
>
> The 'rmmod' process will hang unkillably in the kernel.
>
> Here's an example `dmesg` output from the hung-task watchdog for
> rmmod:
>
>  INFO: task rmmod:1608 blocked for more than 120 seconds.
>  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>  rmmod D 0000000000000000 0 1608 1440 0x00000000
>   ffff880014245c78 0000000000000082 0000000000015bc0 0000000000015bc0
>   ffff880014804890 ffff880014245fd8 0000000000015bc0 ffff8800148044d0
>   0000000000015bc0 ffff880014245fd8 0000000000015bc0 ffff880014804890
>   Call Trace:
>   [<ffffffff81541b6d>] schedule_timeout+0x22d/0x300
>   [<ffffffff812b8716>] ? rb_erase+0xd6/0x160
>   [<ffffffff81052a10>] ? __dequeue_entity+0x30/0x50
>   [<ffffffff8154178b>] wait_for_common+0xdb/0x180
>   [<ffffffff8105a220>] ? default_wake_function+0x0/0x20
>   [<ffffffff815418ed>] wait_for_completion+0x1d/0x20
>   [<ffffffff8107fe55>] flush_cpu_workqueue+0x65/0xa0
>   [<ffffffff8107ff10>] ? wq_barrier_func+0x0/0x20
>   [<ffffffff81080754>] flush_workqueue+0x54/0x80
>   [<ffffffff810b5b24>] __stop_machine+0xf4/0x120
>   [<ffffffff8109d8c0>] ? __try_stop_module+0x0/0x50
>   [<ffffffff810b5d7e>] stop_machine+0x3e/0x60
>   [<ffffffff8109cbd4>] ? find_module+0x34/0x70
>   [<ffffffff8109e1ee>] sys_delete_module+0x17e/0x270
>   [<ffffffff810121b2>] system_call_fastpath+0x16/0x1b
>
> The process is waiting on kstop/0 to wake up and service the stop_cpu
> workqueue work item that it has queued. kstop/0 is marked as
> TASK_RUNNABLE, but doesn't appear to ever be getting scheduled:
>
>     $ ps -f 1609
>     UID PID PPID C STIME TTY STAT TIME CMD
>     root 1609 2 0 14:47 ? R 0:00 [kstop/0]
>
>     $ cat /proc/1609/stack
>     [<ffffffff8107fb6a>] worker_thread+0xda/0x110
>     [<ffffffff81084206>] kthread+0x96/0xa0
>     [<ffffffff810131ea>] child_rip+0xa/0x20
>     [<ffffffffffffffff>] 0xffffffffffffffff
>
> I tracked this behavior down and reported it to the upstream kernel,
> but they say it's not a bug and that it's libcgroup's fault for moving
> kthreadd into a cgroup without RT privs:
> https://lkml.org/lkml/2011/1/5/53
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/libcgroup/+bug/693594/+subscriptions