lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 18 Jan 2010 00:26:47 +0800
From:	Ming Lei <tom.leiming@...il.com>
To:	ebiederm@...ssion.com (Eric W. Biederman)
Cc:	Greg KH <greg@...ah.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Borislav Petkov <petkovbb@...glemail.com>,
	David Airlie <airlied@...ux.ie>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Al Viro <viro@...IV.linux.org.uk>, Tejun Heo <tj@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	linux-pcmcia@...ts.infradead.org,
	Dominik Brodowski <linux@...inikbrodowski.net>
Subject: Re: [PATCH] sysfs: Add lockdep annotations for the sysfs active
 reference

On Sat, 02 Jan 2010 13:37:12 -0800
ebiederm@...ssion.com (Eric W. Biederman) wrote:

> 
> Holding locks over device_del -> kobject_del -> sysfs_deactivate can
> cause deadlocks if those same locks are grabbed in sysfs show or store
> methods.
> 
> The I model s_active count + completion as a sleeping read/write lock.
> I describe to lockdep sysfs_get_active as a read_trylock,
> sysfs_put_active as a read_unlock, and sysfs_deactivate as a
> write_lock and write_unlock pair.  This seems to capture the essence
> for purposes of finding deadlocks, and in my testing gives finds real
> issues and ignores non-issues.
> 
> This brings us back to holding locks over kobject_del is a problem
> that ideally we should find a way of addressing, but at least lockdep
> can tell us about the problems instead of requiring developers to
> debug rare strange system deadlocks, that happen when sysfs files are
> removed while being written to.

The model has hit a possible deadlock in pcmcia, and the lockdep warning
comes when I unplug my wlan card from pcmcia slot.

Looks like socket->skt_mutex is held in remove path, and it is also
grabbed in .stor method.


[ 9207.755883] pcmcia_socket pcmcia_socket0: pccard: card ejected from slot 0
[ 9207.786583] 
[ 9207.786586] =======================================================
[ 9207.786595] [ INFO: possible circular locking dependency detected ]
[ 9207.786602] 2.6.33-rc4-wl #8
[ 9207.786607] -------------------------------------------------------
[ 9207.786614] pccardd/841 is trying to acquire lock:
[ 9207.786620]  (s_active){++++.+}, at: [<ffffffff811637f1>] sysfs_addrm_finish+0x36/0x55
[ 9207.786643] 
[ 9207.786645] but task is already holding lock:
[ 9207.786651]  (&socket->skt_mutex){+.+.+.}, at: [<ffffffff812ed04c>] pccardd+0x15d/0x25f
[ 9207.786669] 
[ 9207.786671] which lock already depends on the new lock.
[ 9207.786674] 
[ 9207.786679] 
[ 9207.786680] the existing dependency chain (in reverse order) is:
[ 9207.786687] 
[ 9207.786688] -> #1 (&socket->skt_mutex){+.+.+.}:
[ 9207.786702]        [<ffffffff810796c0>] __lock_acquire+0xb73/0xd2b
[ 9207.786716]        [<ffffffff8107a36b>] lock_acquire+0xe1/0x105
[ 9207.786726]        [<ffffffff813b5ac5>] __mutex_lock_common+0x59/0x49d
[ 9207.786741]        [<ffffffff813b5fbe>] mutex_lock_nested+0x39/0x3e
[ 9207.786752]        [<ffffffff812ef3ed>] pccard_store_resource+0x6b/0xc5
[ 9207.786763]        [<ffffffff812a55da>] dev_attr_store+0x20/0x22
[ 9207.786775]        [<ffffffff8116259a>] sysfs_write_file+0x108/0x144
[ 9207.786787]        [<ffffffff8110cf48>] vfs_write+0xae/0x10b
[ 9207.786798]        [<ffffffff8110d065>] sys_write+0x4a/0x6e
[ 9207.786808]        [<ffffffff81009bc2>] system_call_fastpath+0x16/0x1b
[ 9207.786822] 
[ 9207.786824] -> #0 (s_active){++++.+}:
[ 9207.786835]        [<ffffffff8107956a>] __lock_acquire+0xa1d/0xd2b
[ 9207.786847]        [<ffffffff8107a36b>] lock_acquire+0xe1/0x105
[ 9207.786857]        [<ffffffff81163230>] sysfs_deactivate+0x8b/0xe0
[ 9207.786868]        [<ffffffff811637f1>] sysfs_addrm_finish+0x36/0x55
[ 9207.786879]        [<ffffffff81161c26>] sysfs_hash_and_remove+0x53/0x6a
[ 9207.786890]        [<ffffffff811629fd>] sysfs_remove_file+0x15/0x17
[ 9207.786900]        [<ffffffff812a650e>] device_remove_file+0x17/0x19
[ 9207.786911]        [<ffffffff81213ef7>] pci_remove_sysfs_dev_files+0x6b/0x10c
[ 9207.786924]        [<ffffffff8120dce1>] pci_stop_bus_device+0x55/0x83
[ 9207.786936]        [<ffffffff8120dd99>] pci_remove_bus_device+0x1a/0xba
[ 9207.786947]        [<ffffffff8120de5f>] pci_remove_behind_bridge+0x26/0x3f
[ 9207.786958]        [<ffffffff812efb96>] cb_free+0x4a/0x4f
[ 9207.786969]        [<ffffffff812ec682>] socket_shutdown+0x91/0xfd
[ 9207.786979]        [<ffffffff812ec88a>] socket_remove+0x4e/0x57
[ 9207.786989]        [<ffffffff812ed08b>] pccardd+0x19c/0x25f
[ 9207.787000]        [<ffffffff810674dd>] kthread+0x7f/0x87
[ 9207.787011]        [<ffffffff8100aa64>] kernel_thread_helper+0x4/0x10
[ 9207.787023] 
[ 9207.787025] other info that might help us debug this:
[ 9207.787027] 
[ 9207.787034] 1 lock held by pccardd/841:
[ 9207.787039]  #0:  (&socket->skt_mutex){+.+.+.}, at: [<ffffffff812ed04c>] pccardd+0x15d/0x25f
[ 9207.787058] 
[ 9207.787060] stack backtrace:
[ 9207.787068] Pid: 841, comm: pccardd Not tainted 2.6.33-rc4-wl #8
[ 9207.787069] Call Trace:
[ 9207.787069]  [<ffffffff8107871d>] print_circular_bug+0xa8/0xb6
[ 9207.787069]  [<ffffffff8107956a>] __lock_acquire+0xa1d/0xd2b
[ 9207.787069]  [<ffffffff811637f1>] ? sysfs_addrm_finish+0x36/0x55
[ 9207.787069]  [<ffffffff8107a36b>] lock_acquire+0xe1/0x105
[ 9207.787069]  [<ffffffff811637f1>] ? sysfs_addrm_finish+0x36/0x55
[ 9207.787069]  [<ffffffff81163230>] sysfs_deactivate+0x8b/0xe0
[ 9207.787069]  [<ffffffff811637f1>] ? sysfs_addrm_finish+0x36/0x55
[ 9207.787069]  [<ffffffff8107760e>] ? trace_hardirqs_off+0xd/0xf
[ 9207.787069]  [<ffffffff813b5897>] ? __mutex_unlock_slowpath+0x119/0x14e
[ 9207.787069]  [<ffffffff811637f1>] sysfs_addrm_finish+0x36/0x55
[ 9207.787069]  [<ffffffff81161c26>] sysfs_hash_and_remove+0x53/0x6a
[ 9207.787069]  [<ffffffff811629fd>] sysfs_remove_file+0x15/0x17
[ 9207.787069]  [<ffffffff812a650e>] device_remove_file+0x17/0x19
[ 9207.787069]  [<ffffffff81213ef7>] pci_remove_sysfs_dev_files+0x6b/0x10c
[ 9207.787069]  [<ffffffff8120dce1>] pci_stop_bus_device+0x55/0x83
[ 9207.787069]  [<ffffffff8120dd99>] pci_remove_bus_device+0x1a/0xba
[ 9207.787069]  [<ffffffff8120de5f>] pci_remove_behind_bridge+0x26/0x3f
[ 9207.787069]  [<ffffffff812efb96>] cb_free+0x4a/0x4f
[ 9207.787069]  [<ffffffff812ec682>] socket_shutdown+0x91/0xfd
[ 9207.787069]  [<ffffffff812ec88a>] socket_remove+0x4e/0x57
[ 9207.787069]  [<ffffffff812ed08b>] pccardd+0x19c/0x25f
[ 9207.787069]  [<ffffffff812eceef>] ? pccardd+0x0/0x25f
[ 9207.787069]  [<ffffffff810674dd>] kthread+0x7f/0x87
[ 9207.787069]  [<ffffffff8100aa64>] kernel_thread_helper+0x4/0x10
[ 9207.787069]  [<ffffffff813b8014>] ? restore_args+0x0/0x30
[ 9207.787069]  [<ffffffff8106745e>] ? kthread+0x0/0x87
[ 9207.787069]  [<ffffffff8100aa60>] ? kernel_thread_helper+0x0/0x10
[ 9207.788150] device: '0000:16:00.0': device_unregister
[ 9207.788166] PM: Removing info for pci:0000:16:00.0
[ 9207.788405] bus: 'pci': remove device 0000:16:00.0



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists