workqueue: Catch more locking problems with flush_work()
If a workqueue is flushed with flush_work() lockdep checking can be circumvented. For example: static DEFINE_MUTEX(mutex); static void my_work(struct work_struct *w) { mutex_lock(&mutex); mutex_unlock(&mutex); } static DECLARE_WORK(work, my_work); static int __init start_test_module(void) { schedule_work(&work); return 0; } module_init(start_test_module); static void __exit stop_test_module(void) { mutex_lock(&mutex); flush_work(&work); mutex_unlock(&mutex); } module_exit(stop_test_module); would not always print a warning when flush_work() was called. In this trivial example nothing could go wrong since we are guaranteed module_init() and module_exit() don't run concurrently, but if the work item is schedule asynchronously we could have a scenario where the work item is running just at the time flush_work() is called resulting in a classic ABBA locking problem. Add a lockdep hint by acquiring and releasing the work item lockdep_map in flush_work() so that we always catch this potential deadlock scenario. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Reviewed-by: Yong Zhang <yong.zhang0@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org>
This commit is contained in:
parent
f5b2552b4e
commit
0976dfc1d0
@ -2509,6 +2509,9 @@ bool flush_work(struct work_struct *work)
|
|||||||
{
|
{
|
||||||
struct wq_barrier barr;
|
struct wq_barrier barr;
|
||||||
|
|
||||||
|
lock_map_acquire(&work->lockdep_map);
|
||||||
|
lock_map_release(&work->lockdep_map);
|
||||||
|
|
||||||
if (start_flush_work(work, &barr, true)) {
|
if (start_flush_work(work, &barr, true)) {
|
||||||
wait_for_completion(&barr.done);
|
wait_for_completion(&barr.done);
|
||||||
destroy_work_on_stack(&barr.work);
|
destroy_work_on_stack(&barr.work);
|
||||||
|
Loading…
Reference in New Issue
Block a user