| 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
| ||
|
Date: Tue, 22 Sep 2009 17:55:43 +0400
From: Alexander Beregalov <a.beregalov@...il.com>
To: Frederic Weisbecker <fweisbec@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Reiserfs <reiserfs-devel@...r.kernel.org>
Subject: Re: [PATCH] kill-the-bkl/reiserfs: Fix induced mm->mmap_sem to
sysfs_mutex dependency
Hi Frederic.
Another very similar warning.
(smp 2*2core)
v2.6.31-7068-g43c1266 plus 193be0ee1 kill-the-bkl/reiserfs: Fix
induced mm->mmap_sem to sysfs_mutex dependency
[ INFO: possible circular locking dependency detected ]
2.6.31-07095-g25a3912 #4
-------------------------------------------------------
udevadm/790 is trying to acquire lock:
(&mm->mmap_sem){++++++}, at: [<c1098942>] might_fault+0x72/0xc0
but task is already holding lock:
(sysfs_mutex){+.+.+.}, at: [<c110813c>] sysfs_readdir+0x7c/0x260
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #5 (sysfs_mutex){+.+.+.}:
[<c1069810>] __lock_acquire+0xc90/0x1290
[<c1069eaa>] lock_acquire+0x9a/0xd0
[<c13ff805>] __mutex_lock_common+0x65/0x440
[<c13ffce0>] mutex_lock_nested+0x40/0x60
[<c1108535>] sysfs_addrm_start+0x35/0xc0
[<c11094d1>] create_dir+0x51/0xb0
[<c1109566>] sysfs_create_dir+0x36/0x60
[<c12356d7>] kobject_add_internal+0xa7/0x270
[<c12359da>] kobject_add_varg+0x3a/0x70
[<c1235a4e>] kobject_init_and_add+0x3e/0x60
[<c10af62d>] sysfs_slab_add+0x7d/0x1e0
[<c10af7ef>] sysfs_add_func+0x5f/0xa0
[<c104d16e>] worker_thread+0x16e/0x270
[<c1051fac>] kthread+0x7c/0x90
[<c1003f5b>] kernel_thread_helper+0x7/0x7c
-> #4 (slub_lock){+++++.}:
[<c1069810>] __lock_acquire+0xc90/0x1290
[<c1069eaa>] lock_acquire+0x9a/0xd0
[<c14000d2>] down_read+0x52/0xb0
[<c15e2497>] slab_cpuup_callback+0x4a/0x196
[<c140481d>] notifier_call_chain+0x4d/0x90
[<c1058095>] __raw_notifier_call_chain+0x25/0x40
[<c15e1c63>] cpu_up+0xdd/0x1a6
[<c15b1403>] kernel_init+0xac/0x1a8
[<c1003f5b>] kernel_thread_helper+0x7/0x7c
-> #3 (cpu_hotplug.lock){+.+.+.}:
[<c1069810>] __lock_acquire+0xc90/0x1290
[<c1069eaa>] lock_acquire+0x9a/0xd0
[<c13ff805>] __mutex_lock_common+0x65/0x440
[<c13ffce0>] mutex_lock_nested+0x40/0x60
[<c15e1c24>] cpu_up+0x9e/0x1a6
[<c15b1403>] kernel_init+0xac/0x1a8
[<c1003f5b>] kernel_thread_helper+0x7/0x7c
-> #2 (cpu_add_remove_lock){+.+.+.}:
[<c1069810>] __lock_acquire+0xc90/0x1290
[<c1069eaa>] lock_acquire+0x9a/0xd0
[<c13ff805>] __mutex_lock_common+0x65/0x440
[<c13ffce0>] mutex_lock_nested+0x40/0x60
[<c103ad9d>] cpu_maps_update_begin+0x1d/0x40
[<c104d9cc>] __create_workqueue_key+0x9c/0x210
[<c113be94>] journal_init+0x9a4/0xa60
[<c112735f>] reiserfs_fill_super+0x35f/0xdf0
[<c10b8618>] get_sb_bdev+0x138/0x180
[<c1124f0d>] get_super_block+0x2d/0x50
[<c10b72f1>] vfs_kern_mount+0x51/0xc0
[<c10b73ed>] do_kern_mount+0x4d/0x100
[<c10d115a>] do_mount+0x21a/0x720
[<c10d16ec>] sys_mount+0x8c/0xe0
[<c15b1d19>] mount_block_root+0xcf/0x26b
[<c15b1f19>] mount_root+0x64/0x7b
[<c15b204c>] prepare_namespace+0x11c/0x167
[<c15b14df>] kernel_init+0x188/0x1a8
[<c1003f5b>] kernel_thread_helper+0x7/0x7c
-> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
[<c1069810>] __lock_acquire+0xc90/0x1290
[<c1069eaa>] lock_acquire+0x9a/0xd0
[<c13ff805>] __mutex_lock_common+0x65/0x440
[<c13ffce0>] mutex_lock_nested+0x40/0x60
[<c1142282>] reiserfs_write_lock_once+0x32/0x70
[<c111c1fb>] reiserfs_get_block+0x6b/0x1510
[<c10e5e48>] do_mpage_readpage+0x168/0x510
[<c10e631f>] mpage_readpages+0xaf/0x100
[<c1118ef5>] reiserfs_readpages+0x25/0x40
[<c108bc2d>] __do_page_cache_readahead+0x1fd/0x2a0
[<c108bcfd>] ra_submit+0x2d/0x50
[<c1083bf6>] filemap_fault+0x436/0x470
[<c109af24>] __do_fault+0x54/0x410
[<c109bdd1>] handle_mm_fault+0x1c1/0x680
[<c14043e5>] do_page_fault+0x115/0x380
[<c1401ff0>] error_code+0x78/0x80
[<c10f45a7>] padzero+0x37/0x50
[<c10f4d4d>] load_elf_binary+0x63d/0x1500
[<c10bc461>] search_binary_handler+0x1a1/0x330
[<c10bcb48>] do_execve+0x1f8/0x270
[<c1001783>] sys_execve+0x33/0x80
[<c10033dc>] syscall_call+0x7/0xb
-> #0 (&mm->mmap_sem){++++++}:
[<c1069dc8>] __lock_acquire+0x1248/0x1290
[<c1069eaa>] lock_acquire+0x9a/0xd0
[<c1098973>] might_fault+0xa3/0xc0
[<c123d611>] copy_to_user+0x41/0x130
[<c10c4f9c>] filldir64+0xcc/0x120
[<c11081ba>] sysfs_readdir+0xfa/0x260
[<c10c525e>] vfs_readdir+0x9e/0xc0
[<c10c52fa>] sys_getdents64+0x7a/0xe0
[<c100334f>] sysenter_do_call+0x12/0x36
other info that might help us debug this:
2 locks held by udevadm/790:
#0: (&type->i_mutex_dir_key){+.+.+.}, at: [<c10c522a>] vfs_readdir+0x6a/0xc0
#1: (sysfs_mutex){+.+.+.}, at: [<c110813c>] sysfs_readdir+0x7c/0x260
stack backtrace:
Pid: 790, comm: udevadm Not tainted 2.6.31-07095-g25a3912 #4
Call Trace:
[<c13fdd64>] ? printk+0x23/0x37
[<c1067738>] print_circular_bug+0xe8/0x100
[<c1069dc8>] __lock_acquire+0x1248/0x1290
[<c1069eaa>] lock_acquire+0x9a/0xd0
[<c1098942>] ? might_fault+0x72/0xc0
[<c1098942>] ? might_fault+0x72/0xc0
[<c1098973>] might_fault+0xa3/0xc0
[<c1098942>] ? might_fault+0x72/0xc0
[<c123d611>] copy_to_user+0x41/0x130
[<c10c4f9c>] filldir64+0xcc/0x120
[<c11081ba>] sysfs_readdir+0xfa/0x260
[<c10c4ed0>] ? filldir64+0x0/0x120
[<c10c525e>] vfs_readdir+0x9e/0xc0
[<c10c4ed0>] ? filldir64+0x0/0x120
[<c10c52fa>] sys_getdents64+0x7a/0xe0
[<c100334f>] sysenter_do_call+0x12/0x36
--
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