[RESEND][PATCH] cpuset: fix possible deadlock in async_rebuild_sched_domains Jan 21, 2009

http://lkml.org/lkml/2009/1/19/564

이 버그는 lockdep를 사용하여 발견된 버그이다.

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.29-rc1-00224-ga652504 #111
-------------------------------------------------------
bash/2968 is trying to acquire lock:
(events){--..}, at: [] flush_work+0x24/0xd8
but task is already holding lock:
(cgroup_mutex){--..}, at: [] cgroup_lock_live_group+0x12/0x29
which lock already depends on the new lock.

보는 것과 같이 circular locking deadlock 상황이 발생할 수 있음을 탐지하였다.
그럼 살펴보자. 어떻게 그런 deadlock이 발생할 수 있을지..
먼저, cgroup_mutex를 소유하고 있는 task가 있다고 말해주고 있다.
이 mutex는 cgroup_lock_live_group에서 소유하였다. 코드를 살펴보자.

cgroup_tasks_write
->cgroup_lock_live_group을 호출하여 cgrup_mutex를 소유한다.
->attach_task_by_pid
->cpuset_attach
->do_migrate_pages
->migrate_prep
->lru_add_drain_all
->schedule_work_on
->flush_work
->lock_map_acuire

반면, async_rebuild_sched_domains에서 호출한 run_workqueue를 살펴보자.

async_rebuild_sched_domains
->schedule_work (이것은 결국 eventd의 run_workqueue에 의해 실행되게 된다.)
->run_workqueue
->lock_map_acquire
->do_rebuild_sched_domains
->cgroup_lock
->cgroup_mutex 소유


위에서 보는 것과 같이 workqueue와 cgroup_mutex에 대해 circular lock이 형성된다.
이 얘기는 flush_work에 의해 완료되야 하는 worker function이 do_rebuild_sched_domains을 실행시킨 run_workqueue에 의해 lock되며 do_rebuild_sched_domains는 cgroup_mutex를 소유하기 위해 cgroup_tasks_write와 race하게 된다.

lockdep는 이와 같이 여러 deadlock 상황을 발견하기 위해 만들어진 설비이다.
하지만 false positive를 만들어내는 상황도 있기 때문에 무조건 lockdep를 믿는 것도 좋지 않다.
많은 분들이 lockdep가 어떻게 동작하는지, 어떻게 사용하는지, 보고된 내용을 어떻게 해석해야 하는지 잘 알지 못하는 것 같다.
barrios는 조만간 lockdep에 대한 내용을 한번 다룰 예정이다.