From patchwork Wed Mar 25 05:06:31 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kenji Kaneshige X-Patchwork-Id: 14239 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n2P56eA9007023 for ; Wed, 25 Mar 2009 05:06:40 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750867AbZCYFGk (ORCPT ); Wed, 25 Mar 2009 01:06:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751374AbZCYFGk (ORCPT ); Wed, 25 Mar 2009 01:06:40 -0400 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:60657 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750867AbZCYFGj (ORCPT ); Wed, 25 Mar 2009 01:06:39 -0400 Received: from m5.gw.fujitsu.co.jp ([10.0.50.75]) by fgwmail6.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id n2P56aV3006541 (envelope-from kaneshige.kenji@jp.fujitsu.com); Wed, 25 Mar 2009 14:06:37 +0900 Received: from smail (m5 [127.0.0.1]) by outgoing.m5.gw.fujitsu.co.jp (Postfix) with ESMTP id 5C5B845DE51; Wed, 25 Mar 2009 14:06:36 +0900 (JST) Received: from s5.gw.fujitsu.co.jp (s5.gw.fujitsu.co.jp [10.0.50.95]) by m5.gw.fujitsu.co.jp (Postfix) with ESMTP id 1C27345DE4F; Wed, 25 Mar 2009 14:06:36 +0900 (JST) Received: from s5.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s5.gw.fujitsu.co.jp (Postfix) with ESMTP id EB7C0E0800C; Wed, 25 Mar 2009 14:06:35 +0900 (JST) Received: from m107.s.css.fujitsu.com (m107.s.css.fujitsu.com [10.249.87.107]) by s5.gw.fujitsu.co.jp (Postfix) with ESMTP id 984D11DB8043; Wed, 25 Mar 2009 14:06:35 +0900 (JST) Received: from m107.css.fujitsu.com (m107 [127.0.0.1]) by m107.s.css.fujitsu.com (Postfix) with ESMTP id 67A8E670002; Wed, 25 Mar 2009 14:06:35 +0900 (JST) Received: from [127.0.0.1] (unknown [10.124.100.137]) by m107.s.css.fujitsu.com (Postfix) with ESMTP id E2965670004; Wed, 25 Mar 2009 14:06:34 +0900 (JST) Message-ID: <49C9BBD7.4040705@jp.fujitsu.com> Date: Wed, 25 Mar 2009 14:06:31 +0900 From: Kenji Kaneshige User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Alex Chiang CC: jbarnes@virtuousgeek.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Trent Piepho Subject: Re: [PATCH v5 09/13] PCI: Introduce /sys/bus/pci/devices/.../remove References: <20090320204327.12275.43010.stgit@bob.kio> <20090320205636.12275.1825.stgit@bob.kio> <49C74FCC.7070308@jp.fujitsu.com> <20090324192905.GA25984@ldl.fc.hp.com> In-Reply-To: <20090324192905.GA25984@ldl.fc.hp.com> Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org Alex Chiang wrote: > * Kenji Kaneshige : >> I still have the following kernel error messages in testing with your >> latest set of patches (Jesse's linux-next). The test case is removing >> e1000e device or its parent bridge by "echo 1 > /sys/bus/pci/devices/ >> .../remove". >> >> [ 537.379995] ============================================= >> [ 537.380124] [ INFO: possible recursive locking detected ] >> [ 537.380128] 2.6.29-rc8-kk #1 >> [ 537.380128] --------------------------------------------- >> [ 537.380128] events/4/56 is trying to acquire lock: >> [ 537.380128] (events){--..}, at: [] flush_workqueue+0x0/0xa0 >> [ 537.380128] >> [ 537.380128] but task is already holding lock: >> [ 537.380128] (events){--..}, at: [] run_workqueue+0x108/0x230 >> [ 537.380128] >> [ 537.380128] other info that might help us debug this: >> [ 537.380128] 3 locks held by events/4/56: >> [ 537.380128] #0: (events){--..}, at: [] run_workqueue+0x108/0x230 >> [ 537.380128] #1: (&ss->work){--..}, at: [] run_workqueue+0x108/0x230 >> [ 537.380128] #2: (pci_remove_rescan_mutex){--..}, at: [] remove_callback+0x21/0x40 > > I still cannot reproduce this lockdep issue, even using your > .config with an e1000e device on an x86_64 kernel. :( > > I tried removing the endpoint, an intermediate bridge device, and > the parent bus. I don't know what I'm doing wrong... > I don't know either... The reproducibility is 100% on my environment. The steps are just boot the system and remove the device. > Can you please try this patch though, and see if it fixes the > warning? It applies on top of my other sysfs patch that > introduces a mutex in sysfs_schedule_callback. Anyway, I confirmed the kernel error messages were gone with the patch against sysfs. Note that I used the following patch I made for testing instead since your patch could not be applied to Jesse's linux-next. Thanks, Kenji Kaneshige fs/sysfs/file.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) --- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Index: linux-next-20090323/fs/sysfs/file.c =================================================================== --- linux-next-20090323.orig/fs/sysfs/file.c 2009-03-25 12:09:37.000000000 +0900 +++ linux-next-20090323/fs/sysfs/file.c 2009-03-25 13:40:10.000000000 +0900 @@ -677,6 +677,7 @@ kfree(ss); } +static struct workqueue_struct *sysfsd_wq; /** * sysfs_schedule_callback - helper to schedule a callback for a kobject * @kobj: object we're acting for. @@ -704,6 +705,17 @@ if (!try_module_get(owner)) return -ENODEV; + + if (!sysfsd_wq) { + sysfsd_wq = create_workqueue("sysfsd"); + if (!sysfsd_wq) { + printk(KERN_ERR + "%s: Could not create workqueue\n", __func__); + WARN_ON(1); + return -ENOMEM; + } + } + ss = kmalloc(sizeof(*ss), GFP_KERNEL); if (!ss) { module_put(owner); @@ -715,7 +727,7 @@ ss->data = data; ss->owner = owner; INIT_WORK(&ss->work, sysfs_schedule_callback_work); - schedule_work(&ss->work); + queue_work(sysfsd_wq, &ss->work); return 0; } EXPORT_SYMBOL_GPL(sysfs_schedule_callback);