History

workqueue: re-add lockdep dependencies for flushing

In flush_work(), we need to create a lockdep dependency so that the following scenario is appropriately tagged as a problem: work_function() { mutex_lock(&mutex); ... } other_function() { mutex_lock(&mutex); flush_work(&work); // or cancel_work_sync(&work); } This is a problem since the work might be running and be blocked on trying to acquire the mutex. Similarly, in flush_workqueue(). These were removed after cross-release partially caught these problems, but now cross-release was reverted anyway. IMHO the removal was erroneous anyway though, since lockdep should be able to catch potential problems, not just actual ones, and cross-release would only have caught the problem when actually invoking wait_for_completion().

Johannes Berg committed 8 years ago

Commit 87915ad1 parent d6e89781 file · +8 −0Browse files

Showing the changes to kernel/workqueue.c (1 of 1 file). Show all

Unified · Split

kernel/workqueue.c+8−0
@@ -2652,6 +2652,9 @@ void flush_workqueue(struct workqueue_struct *wq) · 2651 unmodified lines
2652 if (WARN_ON(!wq_online))2652 if (WARN_ON(!wq_online))
2653 return;2653 return;
2654 2654
2655 lock_map_acquire(&wq->lockdep_map);
2656 lock_map_release(&wq->lockdep_map);
2657
2655 mutex_lock(&wq->mutex);2658 mutex_lock(&wq->mutex);
2656 2659
2657 /*2660 /*
@@ -2905,6 +2908,11 @@ static bool __flush_work(struct work_struct *work, bool from_cancel) · 247 unmodified lines
2905 if (WARN_ON(!wq_online))2908 if (WARN_ON(!wq_online))
2906 return false;2909 return false;
2907 2910
2911 if (!from_cancel) {
2912 lock_map_acquire(&work->lockdep_map);
2913 lock_map_release(&work->lockdep_map);
2914 }
2915
2908 if (start_flush_work(work, &barr, from_cancel)) {2916 if (start_flush_work(work, &barr, from_cancel)) {
2909 wait_for_completion(&barr.done);2917 wait_for_completion(&barr.done);
2910 destroy_work_on_stack(&barr.work);2918 destroy_work_on_stack(&barr.work);