Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932175AbWIETYT (ORCPT ); Tue, 5 Sep 2006 15:24:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932179AbWIETYT (ORCPT ); Tue, 5 Sep 2006 15:24:19 -0400 Received: from einhorn.in-berlin.de ([192.109.42.8]:30116 "EHLO einhorn.in-berlin.de") by vger.kernel.org with ESMTP id S932175AbWIETYS (ORCPT ); Tue, 5 Sep 2006 15:24:18 -0400 X-Envelope-From: stefanr@s5r6.in-berlin.de Message-ID: <44FDCEAD.5070905@s5r6.in-berlin.de> Date: Tue, 05 Sep 2006 21:23:25 +0200 From: Stefan Richter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060720 SeaMonkey/1.0.3 MIME-Version: 1.0 To: Andrew Morton CC: Miles Lane , linux1394-devel@lists.sourceforge.net, LKML , Herbert Xu Subject: Re: 2.6.18-rc5-mm1 + all hotfixes -- INFO: possible recursive locking detected References: <20060905111306.80398394.akpm@osdl.org> In-Reply-To: <20060905111306.80398394.akpm@osdl.org> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2387 Lines: 72 Andrew Morton wrote: > On Tue, 5 Sep 2006 10:37:51 -0700 > "Miles Lane" wrote: > >> ieee1394: Node changed: 0-01:1023 -> 0-00:1023 >> ieee1394: Node changed: 0-02:1023 -> 0-01:1023 >> ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0080880002103eae] >> >> ============================================= >> [ INFO: possible recursive locking detected ] >> 2.6.18-rc5-mm1 #2 >> --------------------------------------------- >> knodemgrd_0/2321 is trying to acquire lock: >> (&s->rwsem){----}, at: [] nodemgr_probe_ne+0x311/0x38d [ieee1394] >> >> but task is already holding lock: >> (&s->rwsem){----}, at: [] nodemgr_host_thread+0x717/0x883 [ieee1394] [...] This information confuses me. These places are not supposed to be the ones where the locks were actually acquired, are they? > That's a 1394 glitch, possibly introduced by git-ieee1394.patch. Or maybe it's older. Nodemgr takes class->subsys.rwsem and device.bus->subsys.rwsem. It always did. Could there be a change in driver core which makes this recursive? Or has it always been recursive? For example, static void nodemgr_update_pdrv(struct node_entry *ne) { struct unit_directory *ud; struct hpsb_protocol_driver *pdrv; struct class *class = &nodemgr_ud_class; struct class_device *cdev; down_read(&class->subsys.rwsem); list_for_each_entry(cdev, &class->children, node) { ud = container_of(cdev, struct unit_directory, class_dev); if (ud->ne != ne || !ud->device.driver) continue; pdrv = container_of(ud->device.driver, struct hpsb_protocol_driver, driver); if (pdrv->update && pdrv->update(ud)) { down_write(&ud->device.bus->subsys.rwsem); device_release_driver(&ud->device); up_write(&ud->device.bus->subsys.rwsem); } } up_read(&class->subsys.rwsem); } Miles, perhaps you should rather unapply all 1394 patches at once. git-ieee1394.patch is alas the lowermost patch of a stack of dependent patches. I somehow expect that the "possible recursive locking" persists even if all the 1394 patches were removed. Thanks in advance, -- Stefan Richter -=====-=-==- =--= --=-= http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/