From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932282AbYETKXf (ORCPT ); Tue, 20 May 2008 06:23:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758122AbYETKX0 (ORCPT ); Tue, 20 May 2008 06:23:26 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:42301 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753550AbYETKXZ (ORCPT ); Tue, 20 May 2008 06:23:25 -0400 Date: Tue, 20 May 2008 03:22:48 -0700 From: Andrew Morton To: Mariusz Kozlowski Cc: linux-kernel@vger.kernel.org Subject: Re: 2.6.26-rc2-mm1: possible circular locking dependency detected Message-Id: <20080520032248.a4374951.akpm@linux-foundation.org> In-Reply-To: <200805201201.34688.m.kozlowski@tuxland.pl> References: <20080514010129.4f672378.akpm@linux-foundation.org> <200805201201.34688.m.kozlowski@tuxland.pl> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.5; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 20 May 2008 12:01:34 +0200 Mariusz Kozlowski wrote: > Hello, > > This lockdep warning is seen when I remove pcmcia wifi card > from the slot. Doesn't happen every time. It's x86_32. > > ======================================================= > [ INFO: possible circular locking dependency detected ] > 2.6.26-rc2-mm1 #2 > ------------------------------------------------------- > pccardd/1037 is trying to acquire lock: > (rtnl_mutex){--..}, at: [] rtnl_lock+0x14/0x16 > > but task is already holding lock: > (&socket->skt_mutex){--..}, at: [] pccardd+0x161/0x28c > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: OK, three locks are involved here. > -> #2 (&socket->skt_mutex){--..}: > [] __lock_acquire+0xf3b/0x103b > [] lock_acquire+0x79/0x92 > [] mutex_lock_nested+0x90/0x290 > [] pccard_register_pcmcia+0x22/0x78 > [] pcmcia_bus_add_socket+0x9f/0xe0 [pcmcia] > [] class_interface_register+0x83/0xb2 > [] 0xded6003a > [] sys_init_module+0x11e/0x18e4 > [] sysenter_past_esp+0x6a/0xa5 > [] 0xffffffff cls->mutex socket->skt_mutex > -> #1 (&cls->mutex){--..}: > [] __lock_acquire+0xf3b/0x103b > [] lock_acquire+0x79/0x92 > [] mutex_lock_nested+0x90/0x290 > [] device_add+0x42f/0x557 > [] netdev_register_kobject+0x76/0x7b > [] register_netdevice+0x22e/0x39a > [] register_netdev+0x37/0x44 > [] loopback_net_init+0x38/0x7d > [] register_pernet_operations+0x18/0x1a > [] register_pernet_device+0x24/0x51 > [] loopback_init+0x12/0x14 > [] kernel_init+0x80/0x227 > [] kernel_thread_helper+0x7/0x10 > [] 0xffffffff rtnl_lock cls->mutex > -> #0 (rtnl_mutex){--..}: > [] __lock_acquire+0xad9/0x103b > [] lock_acquire+0x79/0x92 > [] mutex_lock_nested+0x90/0x290 > [] rtnl_lock+0x14/0x16 > [] unregister_netdev+0x10/0x1f > [] orinoco_cs_detach+0x20/0x32 [orinoco_cs] > [] pcmcia_device_remove+0x3c/0xcf [pcmcia] > [] __device_release_driver+0x5e/0x84 > [] device_release_driver+0x20/0x2b > [] bus_remove_device+0x73/0x8b > [] device_del+0xdb/0x14b > [] device_unregister+0x10/0x1a > [] pcmcia_card_remove+0x76/0x8c [pcmcia] > [] ds_event+0x59/0x9e [pcmcia] > [] send_event+0x7c/0xa8 > [] socket_remove_drivers+0x17/0x19 > [] socket_shutdown+0x13/0xcc > [] socket_remove+0x2b/0x31 > [] pccardd+0x236/0x28c > [] kthread+0x3b/0x5d > [] kernel_thread_helper+0x7/0x10 > [] 0xffffffff cls->mutex rtnl_lock > other info that might help us debug this: > > 1 lock held by pccardd/1037: > #0: (&socket->skt_mutex){--..}, at: [] pccardd+0x161/0x28c > > stack backtrace: > Pid: 1037, comm: pccardd Not tainted 2.6.26-rc2-mm1 #2 > [] print_circular_bug_tail+0x68/0x71 > [] ? print_circular_bug_entry+0x43/0x4b > [] __lock_acquire+0xad9/0x103b > [] ? __lock_acquire+0x37a/0x103b > [] ? __lock_acquire+0x37a/0x103b > [] ? native_sched_clock+0x66/0xaf > [] lock_acquire+0x79/0x92 > [] ? rtnl_lock+0x14/0x16 > [] mutex_lock_nested+0x90/0x290 > [] ? rtnl_lock+0x14/0x16 > [] ? rtnl_lock+0x14/0x16 > [] rtnl_lock+0x14/0x16 > [] unregister_netdev+0x10/0x1f > [] orinoco_cs_detach+0x20/0x32 [orinoco_cs] > [] pcmcia_device_remove+0x3c/0xcf [pcmcia] > [] __device_release_driver+0x5e/0x84 > [] device_release_driver+0x20/0x2b > [] bus_remove_device+0x73/0x8b > [] device_del+0xdb/0x14b > [] device_unregister+0x10/0x1a > [] pcmcia_card_remove+0x76/0x8c [pcmcia] > [] ds_event+0x59/0x9e [pcmcia] > [] ? socket_remove_drivers+0x17/0x19 > [] send_event+0x7c/0xa8 > [] socket_remove_drivers+0x17/0x19 > [] socket_shutdown+0x13/0xcc > [] ? printk+0x20/0x22 > [] socket_remove+0x2b/0x31 > [] pccardd+0x236/0x28c > [] ? schedule+0x2c4/0x46f > [] ? sub_preempt_count+0x76/0xbd > [] ? default_wake_function+0x0/0x12 > [] ? pccardd+0x0/0x28c > [] kthread+0x3b/0x5d > [] ? kthread+0x0/0x5d > [] kernel_thread_helper+0x7/0x10 This bug has always been there, and is now exposed by the conversion of cls->mutex from a semaphore to a mutex. Because lockdep doesn't check semaphores. I don't know how to get this fixed, sorry. I'll just push struct-class-sem-to-mutex-converting.patch at Greg until it sticks, then it will go into mainline, then we'll get a shower of bug reports, including this one, then someone someday will do soemthing about it. Fun.