Messages in this thread | | | Date | Sat, 21 Apr 2012 08:34:01 +0800 | Subject | Re: [PATCHv2] workqueue: Catch more locking problems with flush_work() | From | Yong Zhang <> |
| |
On Sat, Apr 21, 2012 at 8:28 AM, Stephen Boyd <sboyd@codeaurora.org> 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>
Reviewed-by: Yong Zhang <yong.zhang0@gmail.com>
> --- > kernel/workqueue.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/kernel/workqueue.c b/kernel/workqueue.c > index 5abf42f..038cf64 100644 > --- a/kernel/workqueue.c > +++ b/kernel/workqueue.c > @@ -2506,6 +2506,9 @@ bool flush_work(struct work_struct *work) > { > struct wq_barrier barr; > > + lock_map_acquire(&work->lockdep_map); > + lock_map_release(&work->lockdep_map); > + > if (start_flush_work(work, &barr, true)) { > wait_for_completion(&barr.done); > destroy_work_on_stack(&barr.work); > -- > Sent by an employee of the Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. >
-- Only stand for myself -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |