On Mon, Aug 06, 2012 at 01:16:36PM +0200, Linux VServer wrote: > Hi list, > currently I test the 3.5 Kernel with LV patch and got the > following stacktrace: > Starting vservers of type 'default'... > [ 138.008193] > [ 138.009750] =============================== > [ 138.014077] [ INFO: suspicious RCU usage. ] > [ 138.018357] 3.5.0-vs2.3.4 #2 Not tainted > [ 138.022822] ------------------------------- > [ 138.027126] include/linux/cgroup.h:559 suspicious > rcu_dereference_check() usage! > [ 138.034664] > [ 138.034664] other info that might help us debug this: > [ 138.034664] > [ 138.042821] > [ 138.042821] rcu_scheduler_active = 1, debug_locks = 0 > [ 138.049456] 1 lock held by rc/13160: > [ 138.053140] #0: (&p->lock){+.+.+.}, at: [<ffffffff8118ec5a>] > seq_read+0x3a/0x460 > [ 138.061144] > [ 138.061144] stack backtrace: > [ 138.065641] Pid: 13160, comm: rc Not tainted 3.5.0-vs2.3.4 #2 > [ 138.071942] Call Trace: > [ 138.074469] [<ffffffff810acd53>] lockdep_rcu_suspicious+0x103/0x140 > [ 138.080935] [<ffffffff8115f88a>] mem_cgroup_from_task+0x8a/0x90 > [ 138.087063] [<ffffffff8109a4c5>] vx_vsi_meminfo+0x25/0xb0 > [ 138.092654] [<ffffffff8111115b>] si_meminfo+0x7b/0x90 > [ 138.097907] [<ffffffff811d9d8a>] meminfo_proc_show+0x2a/0x510 > [ 138.103843] [<ffffffff8113349c>] ? vma_adjust+0x4ac/0x520 > [ 138.109428] [<ffffffff810ae75a>] ? mark_held_locks+0x7a/0x120 > [ 138.115363] [<ffffffff8165c751>] ? __mutex_lock_common+0x281/0x3d0 > [ 138.121725] [<ffffffff810aeacd>] ? trace_hardirqs_on_caller+0x10d/0x1a0 > [ 138.128550] [<ffffffff8118ec5a>] ? seq_read+0x3a/0x460 > [ 138.133906] [<ffffffff8118ef6b>] ? seq_read+0x34b/0x460 > [ 138.139332] [<ffffffff81154bcf>] ? kmem_cache_alloc+0x3f/0xd0 > [ 138.145299] [<ffffffff8118ed18>] seq_read+0xf8/0x460 > [ 138.150496] [<ffffffff8118ec20>] ? seq_lseek+0x100/0x100 > [ 138.156005] [<ffffffff811ce8a2>] proc_reg_read+0x82/0xc0 > [ 138.161506] [<ffffffff81169cb5>] vfs_read+0xc5/0x190 > [ 138.166661] [<ffffffff81169e6c>] sys_read+0x4c/0x90 > [ 138.171726] [<ffffffff81666979>] system_call_fastpath+0x16/0x1b > The PID referenced had the following commandline: /bin/sh /etc/init.d/rc 3 > ~# vserver-info > Versions: > Kernel: 3.5.0-vs2.3.4 > VS-API: 0x00020308 > VCI: 0x0000000013001f11 > util-vserver: 0.30.216-pre3034; Apr 10 2012, 06:16:38 > Features: > CC: gcc, gcc (Debian 4.4.5-8) 4.4.5 > CPPFLAGS: '' > CFLAGS: '-g -O2 -std=c99 -Wall -pedantic -W -funit-at-a-time' > build/host: x86_64-pc-linux-gnu/x86_64-pc-linux-gnu > Use dietlibc: yes > Build C++ programs: > Build C99 programs: yes > Available APIs: compat,v11,fscompat,v13,net,v21,v22,v23,netv2 > ext2fs Source: e2fsprogs > syscall(2) invocation: alternative > vserver(2) syscall#: 236/glibc > crypto api: nss > python bindings: yes > use library versioning: yes > Paths: > prefix: /usr > sysconf-Directory: /etc > cfg-Directory: /etc/vservers > initrd-Directory: /etc/init.d > pkgstate-Directory: /var/run/vservers > vserver-Rootdir: /vservers > Is this a vanilla issue or vserver related? Linux-VServer issue. please try the following patch and let us know if it a) fixes the issue for you and b) gives the same (correct) values for memory/swap cgroup limits http://vserver.13thfloor.at/ExperimentalT/delta-memcg-fix05.diff thanks in advance, Herbert > Best regards > uranus