Subject: RCU Lock in vx_vsi_meminfo Kernel 3.5
From: Linux VServer <uranus.lv@gmail.com>
Date: Mon, 6 Aug 2012 13:16:36 +0200
Mon, 6 Aug 2012 13:16:36 +0200
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?


Best regards


uranus


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?

Best regards

uranus