sched: Kill the broken and deadlockable cpuset_lock/cpuset_cpus_allowed_locked code
commit897f0b3c3ff40b443c84e271bef19bd6ae885195
authorOleg Nesterov <oleg@redhat.com>
Mon, 15 Mar 2010 09:10:03 +0000 (15 10:10 +0100)
committerIngo Molnar <mingo@elte.hu>
Fri, 2 Apr 2010 18:12:01 +0000 (2 20:12 +0200)
tree6b969149bb59591a1c9485de405639db6c4208d6
parent25c2d55c00c6097e6792ebf21e31342f23b9b768
sched: Kill the broken and deadlockable cpuset_lock/cpuset_cpus_allowed_locked code

This patch just states the fact the cpusets/cpuhotplug interaction is
broken and removes the deadlockable code which only pretends to work.

- cpuset_lock() doesn't really work. It is needed for
  cpuset_cpus_allowed_locked() but we can't take this lock in
  try_to_wake_up()->select_fallback_rq() path.

- cpuset_lock() is deadlockable. Suppose that a task T bound to CPU takes
  callback_mutex. If cpu_down(CPU) happens before T drops callback_mutex
  stop_machine() preempts T, then migration_call(CPU_DEAD) tries to take
  cpuset_lock() and hangs forever because CPU is already dead and thus
  T can't be scheduled.

- cpuset_cpus_allowed_locked() is deadlockable too. It takes task_lock()
  which is not irq-safe, but try_to_wake_up() can be called from irq.

Kill them, and change select_fallback_rq() to use cpu_possible_mask, like
we currently do without CONFIG_CPUSETS.

Also, with or without this patch, with or without CONFIG_CPUSETS, the
callers of select_fallback_rq() can race with each other or with
set_cpus_allowed() pathes.

The subsequent patches try to to fix these problems.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <20100315091003.GA9123@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
include/linux/cpuset.h
kernel/cpuset.c
kernel/sched.c