| 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 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20100118002647.35035e77@tom-lei>
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