Messages in this thread | | | Date | Mon, 23 Apr 2012 11:07:57 -0700 | From | Tejun Heo <> | Subject | Re: [PATCHv2] workqueue: Catch more locking problems with flush_work() |
| |
On Fri, Apr 20, 2012 at 05:28:50PM -0700, Stephen Boyd wrote: > 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>
Applied to wq/for-3.5. Let's see whether it triggers spuriously.
Thanks.
-- tejun
| |