Re: net/bluetooth: workqueue destruction WARNING in hci_unregister_dev

From: Dmitry Vyukov
Date: Mon Sep 05 2016 - 09:14:59 EST


On Mon, Sep 5, 2016 at 3:08 PM, Tejun Heo <tj@xxxxxxxxxx> wrote:
> 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;
> }
> }


Applied this to my test tree.