Hello, On Sat, Sep 03, 2016 at 12:58:33PM +0200, Dmitry Vyukov wrote: > > I've seen it only several times in several months, so I don't it will > > be helpful. > > > Bad news: I hit it again. > On 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of linux-next, so I have > bf389cabb3b8079c23f9762e62b05f291e2d5e99. Hmmm... we're not getting anywhere. I've applied the following patch to wq/for-4.8-fixes so that when this happens the next time we can actually tell what the hell is going wrong. Thanks. ------ 8< ------ >From 278930ada88c972d20025b0f20def27b1a09dff7 Mon Sep 17 00:00:00 2001 From: Tejun Heo <tj@xxxxxxxxxx> Date: Mon, 5 Sep 2016 08:54:06 -0400 Subject: [PATCH] workqueue: dump workqueue state on sanity check failures in destroy_workqueue() destroy_workqueue() performs a number of sanity checks to ensure that the workqueue is empty before proceeding with destruction. However, it's not always easy to tell what's going on just from the warning message. Let's dump workqueue state after sanity check failures to help debugging. Signed-off-by: Tejun Heo <tj@xxxxxxxxxx> Link: http://lkml.kernel.org/r/CACT4Y+Zs6vkjHo9qHb4TrEiz3S4+quvvVQ9VWvj2Mx6pETGb9Q@xxxxxxxxxxxxxx Cc: Dmitry Vyukov <dvyukov@xxxxxxxxxx> --- kernel/workqueue.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index ef071ca..4eaec8b8 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -4021,6 +4021,7 @@ void destroy_workqueue(struct workqueue_struct *wq) for (i = 0; i < WORK_NR_COLORS; i++) { if (WARN_ON(pwq->nr_in_flight[i])) { mutex_unlock(&wq->mutex); + show_workqueue_state(); return; } } @@ -4029,6 +4030,7 @@ void destroy_workqueue(struct workqueue_struct *wq) WARN_ON(pwq->nr_active) || WARN_ON(!list_empty(&pwq->delayed_works))) { mutex_unlock(&wq->mutex); + show_workqueue_state(); return; } } -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
