Upstream kernel says this isn't a kernel bug: https://lkml.org/lkml/2011/1/5/53
** Package changed: linux (Ubuntu) => libcgroup (Ubuntu) ** Summary changed: - rmmod hangs if cgroup-bin is installed + cgroup-bin should not move kthreadd into a default cgroup ** Description changed: 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 can reproduce this bug on Karmic's kernel, but it does not seem to be - present in Maverick. - - [deleting all the apport crap because I can reproduce this on a stock - LiveCD, so it's just noise] + 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 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/693594 Title: cgroup-bin should not move kthreadd into a default cgroup -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
