From patchwork Tue Mar 22 08:09:50 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jiri Slaby X-Patchwork-Id: 600502 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 3qTll52KPSz9s2Q for ; Tue, 22 Mar 2016 19:11:13 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758190AbcCVIKD (ORCPT ); Tue, 22 Mar 2016 04:10:03 -0400 Received: from mail-wm0-f50.google.com ([74.125.82.50]:37865 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755473AbcCVIJ4 (ORCPT ); Tue, 22 Mar 2016 04:09:56 -0400 Received: by mail-wm0-f50.google.com with SMTP id p65so151645220wmp.0; Tue, 22 Mar 2016 01:09:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=HoaaryB3WKOkBAPe/8tSLiZ1ITDMaLu0cPtLiapiFss=; b=KNbU8E/4Wc11Hx8JchysBYzxOpOsWoQfVuRTlWpTktuktCoAL5cu1NYWodmAZJCJ5e rEJhaDZesOZJkTfGvW+kgHo7oA6UrSGHaThTPSoXaKGFMBNyjZ7nmSbfsrxI1QcsuhUa 7dHsaSxUi0kN1yVslIys1WrWwQrBSCYIBn3fwlIXII87b77gAriVAej8mbsIe6RvqIZw UkVJFWe8yKOD9RpacBC2+tHnS9fFka6XSLzfcm1LabujM6Yo+fP0VoDTuBeIctd8f0Wl ChG5FyswK5/vwepBL/bv637xR0Q3A4auJxAa2N8ZktAIxZodBe+06huloOag7Faq6vhP l+qg== X-Gm-Message-State: AD7BkJLEA2ArKRVVvvr3wOpDhTIZ7sZb6wUbTKwnl/1BfXuk+ZH7AvzhsNCRJI4zGjNyPQ== X-Received: by 10.194.60.200 with SMTP id j8mr34249166wjr.124.1458634193068; Tue, 22 Mar 2016 01:09:53 -0700 (PDT) Received: from ?IPv6:2a01:4240:2e27:ad85:aaaa::19f? ([2a01:4240:2e27:ad85:aaaa::19f]) by smtp.gmail.com with ESMTPSA id j10sm28899709wjb.46.2016.03.22.01.09.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Mar 2016 01:09:51 -0700 (PDT) Subject: Re: net/bluetooth: workqueue destruction WARNING in hci_unregister_dev To: Tejun Heo , Dmitry Vyukov References: <56C5CE85.6090808@suse.cz> <20160218174427.GG13177@mtj.duckdns.org> <56C6EC62.8080107@suse.cz> <56C70618.3010902@suse.cz> <20160302154507.GC4282@mtj.duckdns.org> <56D7FFE1.90900@suse.cz> <20160311171205.GB24046@htj.duckdns.org> <56EA9C4D.2080803@suse.cz> <20160318205231.GO20028@mtj.duckdns.org> <56F01A1C.40208@suse.cz> Cc: Marcel Holtmann , Gustavo Padovan , Johan Hedberg , "David S. Miller" , linux-bluetooth@vger.kernel.org, netdev , LKML , syzkaller , Kostya Serebryany , Alexander Potapenko , Sasha Levin , Eric Dumazet , Takashi Iwai From: Jiri Slaby Message-ID: <56F0FDCE.1040701@suse.cz> Date: Tue, 22 Mar 2016 09:09:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56F01A1C.40208@suse.cz> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 03/21/2016, 04:58 PM, Jiri Slaby wrote: > Hello, > > On 03/18/2016, 09:52 PM, Tejun Heo wrote: >> On Thu, Mar 17, 2016 at 01:00:13PM +0100, Jiri Slaby wrote: >>>>> I have not done that yet, but today, I see: >>>>> destroy_workqueue: name='req_hci0' pwq=ffff88002f590300 >>>>> wq->dfl_pwq=ffff88002f591e00 pwq->refcnt=2 pwq->nr_active=0 delayed_works: >>>>> pwq 12: cpus=0-1 node=0 flags=0x4 nice=-20 active=0/1 >>>>> in-flight: 18568:wq_barrier_func >>>> >>>> So, this means that there's flush_work() racing against workqueue >>>> destruction, which can't be safe. :( >>> >>> But I cannot trigger the WARN_ONs in the attached patch, so I am >>> confused how this can happen :(. (While I am still seeing the destroy >>> WARNINGs.) >> >> So, no operations should be in progress when destroy_workqueue() is >> called. If somebody was flushing a work item, the flush call must >> have returned before destroy_workqueue() was invoked, which doesn't >> seem to be the case here. Can you trigger BUG_ON() or sysrq-t when >> the above triggers? There must be a task which is flushing a work >> item there and it shouldn't be difficult to pinpoint what's going on >> from it. > > The output of sysrq-t is here (> 200k), but I cannot see anything > suspicious in it: > http://www.fi.muni.cz/~xslaby/sklad/panics/jctl.txt Hmm, so I seem I cannot reproduce with this hunk: I cannot explain why though. I do not see how it matters in this particular case... Dmitry, could you apply it too? But I don't know how often you see the warning. PS. next on the table is the gsm tty warning. thanks, --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -3139,10 +3139,10 @@ void hci_unregister_dev(struct hci_dev *hdev) list_del(&hdev->list); write_unlock(&hci_dev_list_lock); - hci_dev_do_close(hdev); - cancel_work_sync(&hdev->power_on); + hci_dev_do_close(hdev); + if (!test_bit(HCI_INIT, &hdev->flags) && !hci_dev_test_flag(hdev, HCI_SETUP) && !hci_dev_test_flag(hdev, HCI_CONFIG)) {