From patchwork Tue Mar 24 19:29:05 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Chiang X-Patchwork-Id: 14090 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 n2OJToiN023191 for ; Tue, 24 Mar 2009 19:29:50 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756605AbZCXT3K (ORCPT ); Tue, 24 Mar 2009 15:29:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756422AbZCXT3J (ORCPT ); Tue, 24 Mar 2009 15:29:09 -0400 Received: from g4t0015.houston.hp.com ([15.201.24.18]:3607 "EHLO g4t0015.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753160AbZCXT3I (ORCPT ); Tue, 24 Mar 2009 15:29:08 -0400 Received: from g4t0018.houston.hp.com (g4t0018.houston.hp.com [16.234.32.27]) by g4t0015.houston.hp.com (Postfix) with ESMTP id CD47E838C; Tue, 24 Mar 2009 19:29:06 +0000 (UTC) Received: from ldl.fc.hp.com (ldl.fc.hp.com [15.11.146.30]) by g4t0018.houston.hp.com (Postfix) with ESMTP id 8D84910005; Tue, 24 Mar 2009 19:29:06 +0000 (UTC) Received: by ldl.fc.hp.com (Postfix, from userid 17609) id 2E7DE39C001; Tue, 24 Mar 2009 13:29:05 -0600 (MDT) Date: Tue, 24 Mar 2009 13:29:05 -0600 From: Alex Chiang To: Kenji Kaneshige 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 Message-ID: <20090324192905.GA25984@ldl.fc.hp.com> References: <20090320204327.12275.43010.stgit@bob.kio> <20090320205636.12275.1825.stgit@bob.kio> <49C74FCC.7070308@jp.fujitsu.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <49C74FCC.7070308@jp.fujitsu.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org * 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... 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. Thanks. /ac --- 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 diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index 289c43a..7cc4dc0 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -667,6 +667,7 @@ struct sysfs_schedule_callback_struct { struct work_struct work; }; +static struct workqueue_struct *sysfs_workqueue; static DEFINE_MUTEX(sysfs_workq_mutex); static LIST_HEAD(sysfs_workq); static void sysfs_schedule_callback_work(struct work_struct *work) @@ -720,6 +721,12 @@ int sysfs_schedule_callback(struct kobject *kobj, void (*func)(void *), } mutex_unlock(&sysfs_workq_mutex); + if (sysfs_workqueue == NULL) { + sysfs_workqueue = create_workqueue("sysfsqueue"); + if (sysfs_workqueue == NULL) + return -ENOMEM; + } + ss = kmalloc(sizeof(*ss), GFP_KERNEL); if (!ss) { module_put(owner); @@ -735,7 +742,7 @@ int sysfs_schedule_callback(struct kobject *kobj, void (*func)(void *), mutex_lock(&sysfs_workq_mutex); list_add_tail(&ss->workq_list, &sysfs_workq); mutex_unlock(&sysfs_workq_mutex); - schedule_work(&ss->work); + queue_work(sysfs_workqueue, &ss->work); return 0; } EXPORT_SYMBOL_GPL(sysfs_schedule_callback);