On Tue, Jun 05, 2012 at 01:30:47AM +0300, Kirill A. Shutemov wrote:
[...]
> Хорошо б увидеть на чём залипают процессы с обоих строн.
> 
> После 'echo t > /proc/sysrq-trigger' чё-нить интересное относительно этих
> процессов в dmesg есть?

Да, есть:
[294898.737372] hasher-priv     D ffffffff8160c120     0 23921  23920 0x00000000
[294898.737372]  ffff8807e6291bf8 0000000000000046 0000000000000086 ffff8807f5142040
[294898.737372]  0000000000013100 ffff8807e6291fd8 0000000000013100 ffff8807e6290000
[294898.737372]  0000000000013100 0000000000013100 ffff8807e6291fd8 0000000000013100
[294898.737372] Call Trace:
[294898.737372]  [<ffffffff81443a2a>] schedule+0x3a/0x50
[294898.737372]  [<ffffffff81441e7d>] schedule_timeout+0x1cd/0x2c0
[294898.737372]  [<ffffffff811f8f87>] ? mqueue_destroy_inode+0x17/0x20
[294898.737372]  [<ffffffff81443044>] wait_for_common+0xc4/0x160
[294898.737372]  [<ffffffff8107af50>] ? try_to_wake_up+0x2a0/0x2a0
[294898.737372]  [<ffffffff810d63b0>] ? call_rcu_sched+0x10/0x20
[294898.737372]  [<ffffffff810d63a0>] ? call_rcu_bh+0x20/0x20
[294898.737372]  [<ffffffff81443188>] wait_for_completion+0x18/0x20
[294898.737372]  [<ffffffff810d5a9b>] _rcu_barrier.clone.31+0x9b/0xb0
[294898.737372]  [<ffffffff810d5ac0>] rcu_barrier_sched+0x10/0x20
[294898.737372]  [<ffffffff810d5ad9>] rcu_barrier+0x9/0x10
[294898.737372]  [<ffffffff811602c9>] deactivate_locked_super+0x49/0x90
[294898.737372]  [<ffffffff81160d35>] deactivate_super+0x45/0x60
[294898.737372]  [<ffffffff8117ad74>] mntput_no_expire+0x104/0x150
[294898.737372]  [<ffffffff8117addc>] mntput+0x1c/0x30
[294898.737372]  [<ffffffff8117cda7>] kern_unmount+0x27/0x30
[294898.737372]  [<ffffffff811faeb0>] mq_put_mnt+0x10/0x20
[294898.737372]  [<ffffffff811fb57f>] put_ipc_ns+0x3f/0xb0
[294898.737372]  [<ffffffff81071f5c>] free_nsproxy+0x3c/0xa0
[294898.737372]  [<ffffffff81072143>] switch_task_namespaces+0x33/0x40
[294898.737372]  [<ffffffff8107215b>] exit_task_namespaces+0xb/0x10
[294898.737372]  [<ffffffff8104f154>] do_exit+0x4b4/0x8a0
[294898.737372]  [<ffffffff8104f7e3>] do_group_exit+0x53/0xc0
[294898.737372]  [<ffffffff8104f862>] sys_exit_group+0x12/0x20
[294898.737372]  [<ffffffff8144c939>] system_call_fastpath+0x16/0x1b

Другими словами, что-то не так в ядре с CLONE_NEWIPC, и это воспроизводится на
существенно более простых примерах, чем hasher-priv:

# time unshare -i /bin/true
0.00user 0.00system 0:10.55elapsed 0%CPU (0avgtext+0avgdata 1232maxresident)k
0inputs+0outputs (0major+169minor)pagefaults 0swaps

$ echo -e '#include <sched.h>\nint main(void){return unshare(CLONE_NEWIPC)<0;}' | gcc -xc -O2 -Wall - -o unshare-i
# time ./unshare-i
0.00user 0.00system 0:05.55elapsed 0%CPU (0avgtext+0avgdata 1424maxresident)k
0inputs+0outputs (0major+120minor)pagefaults 0swaps

On Tue, Jun 05, 2012 at 01:35:36AM +0300, Led wrote:
> А
> grep cgroup /proc/mounts
> при этом пустой?

# grep -c cgroup /proc/mounts
0


-- 
ldv