From patchwork Fri Sep 16 20:24:04 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tejun Heo X-Patchwork-Id: 671118 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3sbRZv09KSz9s65 for ; Sat, 17 Sep 2016 06:24:23 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=WPsdSxq3; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965332AbcIPUYK (ORCPT ); Fri, 16 Sep 2016 16:24:10 -0400 Received: from mail-yb0-f170.google.com ([209.85.213.170]:34404 "EHLO mail-yb0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933696AbcIPUYH (ORCPT ); Fri, 16 Sep 2016 16:24:07 -0400 Received: by mail-yb0-f170.google.com with SMTP id x93so56941161ybh.1; Fri, 16 Sep 2016 13:24:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Jn89lO1GmagRg45tFRP60X5OA1Q+uBBUKoVzyOD+Mes=; b=WPsdSxq3TxpIB0Ha+FeTaCHhOn7LDZ4+kAfcm+2wv6ImbuHlKWfRp97LS8PA4Fj1Lq +66bLzVq1kAAxMFYtnWugM4pjMmeG3T2pHHr2SBr99jO47XI+m9lLGFJlAailyn5qI69 lDEat9Da982hsMhczIslhZwrkheqfsNt50uefENrgPKx9CHJm4dlkadYLe74Zn9+qgjx 1Tn/J1j30whXI5B3BB5siji5pZt0A9/tC3tKoN+y3EIx76Nc+p5fY0S47G9DbVcPVbwi v9oVmmqh8fqWBUSDAMxUSoLxK20mS91dcA/mDVNnmHt5bavooY+KFHrz5E5e8tFH61oZ WZ7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=Jn89lO1GmagRg45tFRP60X5OA1Q+uBBUKoVzyOD+Mes=; b=ebFepzmRaV14fSCFeRsXNCdlr5g7d88B0rOCCLyUSxWPh2WBNnfO6mu8DEba8OQ3H6 aWrqf7C3bPZ6bTigJzEfiV81d11+N32Mkch951RVDCI/f+FbnbTsw61dgffh/OYh2i6N pHx/jx/WXfRjIykXO47BZ1p5qmgcQc+Rc2mJ0iSGemMOyNkx6cR4f0JXJ2F9jdjz5xzP QEHHsFlD8IWibzbPOUydFLwmNVLu3l41LNh5+FSAw8hTHRUlldqwa5wIuXRzroLyxBzx xJ36BaOnbWmpztcJdqOXSMFrFEQcZrujJXL/DHx5GtABTGk3osHuRqwokit7FB5gTM03 OKOw== X-Gm-Message-State: AE9vXwNrFtcL4QZiBXXNT68kSRXdd5S+3amgp1Iau5cjrkVp5vptuUQ6GkXBu22Bnwd/fQ== X-Received: by 10.37.63.134 with SMTP id m128mr15639277yba.26.1474057446386; Fri, 16 Sep 2016 13:24:06 -0700 (PDT) Received: from localhost ([2620:10d:c091:200::8:de2]) by smtp.gmail.com with ESMTPSA id 204sm4212675yww.9.2016.09.16.13.24.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Sep 2016 13:24:05 -0700 (PDT) Date: Fri, 16 Sep 2016 16:24:04 -0400 From: Tejun Heo To: Jiri Slaby Cc: Dmitry Vyukov , Marcel Holtmann , Gustavo Padovan , Johan Hedberg , "David S. Miller" , linux-bluetooth , netdev , LKML , syzkaller , Kostya Serebryany , Alexander Potapenko , Eric Dumazet , Takashi Iwai Subject: Re: net/bluetooth: workqueue destruction WARNING in hci_unregister_dev Message-ID: <20160916202404.GE26371@htj.duckdns.org> References: <20160318205231.GO20028@mtj.duckdns.org> <56F01A1C.40208@suse.cz> <56F0FDCE.1040701@suse.cz> <20160905130832.GD20784@mtj.duckdns.org> <20160913153520.GC21123@htj.duckdns.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.0 (2016-08-17) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hello, On Tue, Sep 13, 2016 at 08:14:40PM +0200, Jiri Slaby wrote: > I assume Dmitry sees the same what I am still seeing, so I reported this > some time ago: > https://lkml.org/lkml/2016/3/21/492 > > This warning is trigerred there and still occurs with "HEAD": > (pwq != wq->dfl_pwq) && (pwq->refcnt > 1) > and the state dump is in the log empty too: > destroy_workqueue: name='hci0' pwq=ffff88006b5c8f00 > wq->dfl_pwq=ffff88006b5c9b00 pwq->refcnt=2 pwq->nr_active=0 delayed_works: > pwq 13: > cpus=2-3 node=1 flags=0x4 nice=-20 active=0/1 > in-flight: 2669:wq_barrier_func Hmmm... I think it could be from rescuer holding reference on the pwq. Both cases have WQ_MEM_RECLAIM and it could be that rescuer was still in flight (even without work items pending) when the sanity checks were done. The following patch moves the sanity checks after rescuer destruction. Dmitry, Jiri, can you please see whether the warning goes away with this patch? Thanks. diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 984f6ff..e8046a1 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -4042,8 +4042,7 @@ void destroy_workqueue(struct workqueue_struct *wq) } } - if (WARN_ON((pwq != wq->dfl_pwq) && (pwq->refcnt > 1)) || - WARN_ON(pwq->nr_active) || + if (WARN_ON(pwq->nr_active) || WARN_ON(!list_empty(&pwq->delayed_works))) { mutex_unlock(&wq->mutex); show_workqueue_state(); @@ -4080,6 +4079,7 @@ void destroy_workqueue(struct workqueue_struct *wq) for_each_node(node) { pwq = rcu_access_pointer(wq->numa_pwq_tbl[node]); RCU_INIT_POINTER(wq->numa_pwq_tbl[node], NULL); + WARN_ON((pwq != wq->dfl_pwq) && (pwq->refcnt != 1)); put_pwq_unlocked(pwq); } @@ -4089,6 +4089,7 @@ void destroy_workqueue(struct workqueue_struct *wq) */ pwq = wq->dfl_pwq; wq->dfl_pwq = NULL; + WARN_ON(pwq->refcnt != 1); put_pwq_unlocked(pwq); } }