1. 01 2月, 2009 3 次提交
  2. 19 1月, 2009 1 次提交
    • M
      cpuset: fix possible deadlock in async_rebuild_sched_domains · f90d4118
      Miao Xie 提交于
      Lockdep reported some possible circular locking info when we tested cpuset on
      NUMA/fake NUMA box.
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      2.6.29-rc1-00224-ga6525042 #111
      -------------------------------------------------------
      bash/2968 is trying to acquire lock:
       (events){--..}, at: [<ffffffff8024c8cd>] flush_work+0x24/0xd8
      
      but task is already holding lock:
       (cgroup_mutex){--..}, at: [<ffffffff8026ad1e>] cgroup_lock_live_group+0x12/0x29
      
      which lock already depends on the new lock.
      ......
      -------------------------------------------------------
      
      Steps to reproduce:
      # mkdir /dev/cpuset
      # mount -t cpuset xxx /dev/cpuset
      # mkdir /dev/cpuset/0
      # echo 0 > /dev/cpuset/0/cpus
      # echo 0 > /dev/cpuset/0/mems
      # echo 1 > /dev/cpuset/0/memory_migrate
      # cat /dev/zero > /dev/null &
      # echo $! > /dev/cpuset/0/tasks
      
      This is because async_rebuild_sched_domains has the following lock sequence:
      run_workqueue(async_rebuild_sched_domains)
      	-> do_rebuild_sched_domains -> cgroup_lock
      
      But, attaching tasks when memory_migrate is set has following:
      cgroup_lock_live_group(cgroup_tasks_write)
      	-> do_migrate_pages -> flush_work
      
      This patch fixes it by using a separate workqueue thread.
      Signed-off-by: NMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f90d4118
  3. 18 1月, 2009 4 次提交
  4. 17 1月, 2009 32 次提交