[Devel] [PATCH vz8] kernel/cgroup: remove unnecessary cgroup_mutex lock.

Andrey Ryabinin aryabinin at virtuozzo.com
Fri Oct 9 19:23:10 MSK 2020


Stopping container causes the lockdep to complain (see report bellow).
We can avoid it simply by removing cgroup_mutex lock from
cgroup_mark_ve_root(). I believe it's not needed there, it seems to be
added just in case.

 WARNING: possible circular locking dependency detected
 4.18.0-193.6.3.vz8.4.6+debug #1 Not tainted
 ------------------------------------------------------
 vzctl/36606 is trying to acquire lock:
 ffff88814b195ca0 (kn->count#338){++++}, at: kernfs_remove_by_name_ns+0x40/0x80

 but task is already holding lock:
 ffffffff9cf75a90 (cgroup_mutex){+.+.}, at: cgroup_kn_lock_live+0x106/0x390

 which lock already depends on the new lock.
 the existing dependency chain (in reverse order) is:

 -> #2 (cgroup_mutex){+.+.}:
        __mutex_lock+0x163/0x13d0
        cgroup_mark_ve_root+0x1d/0x2e0
        ve_state_write+0xb81/0xdc0
        cgroup_file_write+0x2da/0x7a0
        kernfs_fop_write+0x255/0x410
        vfs_write+0x157/0x460
        ksys_write+0xb8/0x170
        do_syscall_64+0xa5/0x4d0
        entry_SYSCALL_64_after_hwframe+0x6a/0xdf

 -> #1 (&ve->op_sem){++++}:
        down_write+0xa0/0x3d0
        ve_state_write+0x6b/0xdc0
        cgroup_file_write+0x2da/0x7a0
        kernfs_fop_write+0x255/0x410
        vfs_write+0x157/0x460
        ksys_write+0xb8/0x170
        do_syscall_64+0xa5/0x4d0
        entry_SYSCALL_64_after_hwframe+0x6a/0xdf

 -> #0 (kn->count#338){++++}:
        __lock_acquire+0x22cb/0x48c0
        lock_acquire+0x14f/0x3b0
        __kernfs_remove+0x61e/0x810
        kernfs_remove_by_name_ns+0x40/0x80
        cgroup_addrm_files+0x531/0x940
        css_clear_dir+0xfb/0x200
        kill_css+0x8f/0x120
        cgroup_destroy_locked+0x246/0x5e0
        cgroup_rmdir+0x2f/0x2c0
        kernfs_iop_rmdir+0x131/0x1b0
        vfs_rmdir+0x142/0x3c0
        do_rmdir+0x2b2/0x340
        do_syscall_64+0xa5/0x4d0
        entry_SYSCALL_64_after_hwframe+0x6a/0xdf

 other info that might help us debug this:

 Chain exists of:
   kn->count#338 --> &ve->op_sem --> cgroup_mutex

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(cgroup_mutex);
                                lock(&ve->op_sem);
                                lock(cgroup_mutex);
   lock(kn->count#338);

                *** DEADLOCK ***

 4 locks held by vzctl/36606:
  #0: ffff88813c02c890 (sb_writers#7){.+.+}, at: mnt_want_write+0x3c/0xa0
  #1: ffff88814414ad48 (&type->i_mutex_dir_key#5/1){+.+.}, at: do_rmdir+0x23c/0x340
  #2: ffff88811d3054e8 (&type->i_mutex_dir_key#5){++++}, at: vfs_rmdir+0xb6/0x3c0
  #3: ffffffff9cf75a90 (cgroup_mutex){+.+.}, at: cgroup_kn_lock_live+0x106/0x390

 Call Trace:
  dump_stack+0x9a/0xf0
  check_noncircular+0x317/0x3c0
  __lock_acquire+0x22cb/0x48c0
  lock_acquire+0x14f/0x3b0
  __kernfs_remove+0x61e/0x810
  kernfs_remove_by_name_ns+0x40/0x80
  cgroup_addrm_files+0x531/0x940
  css_clear_dir+0xfb/0x200
  kill_css+0x8f/0x120
  cgroup_destroy_locked+0x246/0x5e0
  cgroup_rmdir+0x2f/0x2c0
  kernfs_iop_rmdir+0x131/0x1b0
  vfs_rmdir+0x142/0x3c0
  do_rmdir+0x2b2/0x340
  do_syscall_64+0xa5/0x4d0
  entry_SYSCALL_64_after_hwframe+0x6a/0xdf

https://jira.sw.ru/browse/PSBM-120670
Signed-off-by: Andrey Ryabinin <aryabinin at virtuozzo.com>
---
 kernel/cgroup/cgroup.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 8420f3547f1a..08137d43f3ab 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -1883,7 +1883,6 @@ void cgroup_mark_ve_root(struct ve_struct *ve)
 	struct css_set *cset;
 	struct cgroup *cgrp;
 
-	mutex_lock(&cgroup_mutex);
 	spin_lock_irq(&css_set_lock);
 
 	rcu_read_lock();
@@ -1899,7 +1898,6 @@ void cgroup_mark_ve_root(struct ve_struct *ve)
 	rcu_read_unlock();
 
 	spin_unlock_irq(&css_set_lock);
-	mutex_unlock(&cgroup_mutex);
 }
 
 static struct cgroup *cgroup_get_ve_root1(struct cgroup *cgrp)
-- 
2.26.2



More information about the Devel mailing list