Re: [patch] x86: some lock annotations for user copy paths

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Ingo Molnar
Date: Wednesday, September 10, 2008 - 5:32 am

here's another one found on another box:

[  574.380319] =======================================================
[  574.380381] [ INFO: possible circular locking dependency detected ]
[  574.380413] 2.6.27-rc6-tip #30918
[  574.380440] -------------------------------------------------------
[  574.380472] sshd/8255 is trying to acquire lock:
[  574.380500]  (&sb->s_type->i_mutex_key#9){--..}, at: [<ffffffff802d5aab>] do_truncate+0x59/0x83
[  574.380628] 
[  574.380629] but task is already holding lock:
[  574.380679]  (&mm->mmap_sem){----}, at: [<ffffffff80249775>] sys32_mmap2+0x64/0xa7
[  574.380781] 
[  574.380781] which lock already depends on the new lock.
[  574.380782] 
[  574.380857] 
[  574.380857] the existing dependency chain (in reverse order) is:
[  574.380910] 
[  574.380911] -> #1 (&mm->mmap_sem){----}:
[  574.381025]        [<ffffffff80281979>] __lock_acquire+0x9b4/0xb3b
[  574.381081]        [<ffffffff80282499>] lock_acquire+0x8d/0xba
[  574.381219]        [<ffffffff802a94ff>] iov_iter_fault_in_readable+0x84/0x169
[  574.381359]        [<ffffffff802aae18>] generic_file_buffered_write+0x119/0x5ad
[  574.381584]        [<ffffffff802ab6cb>] __generic_file_aio_write_nolock+0x260/0x294
[  574.381809]        [<ffffffff802ab768>] generic_file_aio_write+0x69/0xc5
[  574.381948]        [<ffffffff802d68e2>] do_sync_write+0xeb/0x132
[  574.382086]        [<ffffffff802d6f28>] vfs_write+0xa7/0xe1
[  574.382222]        [<ffffffff802d701c>] sys_write+0x47/0x6d
[  574.382359]        [<ffffffff802481b7>] cstar_dispatch+0x7/0x4b
[  574.382496]        [<ffffffffffffffff>] 0xffffffffffffffff
[  574.382635] 
[  574.382636] -> #0 (&sb->s_type->i_mutex_key#9){--..}:
[  574.382942]        [<ffffffff8028181b>] __lock_acquire+0x856/0xb3b
[  574.383080]        [<ffffffff80282499>] lock_acquire+0x8d/0xba
[  574.383218]        [<ffffffff80b77600>] __mutex_lock_common+0xe4/0x333
[  574.383358]        [<ffffffff80b778e9>] mutex_lock_nested+0x30/0x35
[  574.383495]        [<ffffffff802d5aab>] do_truncate+0x59/0x83
[  574.383633]        [<ffffffff802cbbf7>] shmem_file_setup+0xcf/0x106
[  574.383772]        [<ffffffff802cbc50>] shmem_zero_setup+0x22/0x5e
[  574.383910]        [<ffffffff802bfc92>] mmap_region+0x250/0x438
[  574.384031]        [<ffffffff802c047f>] do_mmap_pgoff+0x2fe/0x363
[  574.384031]        [<ffffffff8024978e>] sys32_mmap2+0x7d/0xa7
[  574.384031]        [<ffffffff802481b7>] cstar_dispatch+0x7/0x4b
[  574.384031]        [<ffffffffffffffff>] 0xffffffffffffffff
[  574.384031] 
[  574.384031] other info that might help us debug this:
[  574.384031] 
[  574.384031] 1 lock held by sshd/8255:
[  574.384031]  #0:  (&mm->mmap_sem){----}, at: [<ffffffff80249775>] sys32_mmap2+0x64/0xa7
[  574.384031] 
[  574.384031] stack backtrace:
[  574.384031] Pid: 8255, comm: sshd Not tainted 2.6.27-rc6-tip #30918
[  574.384031] Call Trace:
[  574.384031]  [<ffffffff80280fba>] print_circular_bug_tail+0x71/0x7c
[  574.384031]  [<ffffffff8028181b>] __lock_acquire+0x856/0xb3b
[  574.384031]  [<ffffffff80282499>] lock_acquire+0x8d/0xba
[  574.384031]  [<ffffffff802d5aab>] ? do_truncate+0x59/0x83
[  574.384031]  [<ffffffff80b77600>] __mutex_lock_common+0xe4/0x333
[  574.384031]  [<ffffffff802d5aab>] ? do_truncate+0x59/0x83
[  574.384031]  [<ffffffff802d5aab>] ? do_truncate+0x59/0x83
[  574.384031]  [<ffffffff804e475f>] ? _raw_spin_unlock+0x8e/0x93
[  574.384031]  [<ffffffff80b778e9>] mutex_lock_nested+0x30/0x35
[  574.384031]  [<ffffffff802d5aab>] do_truncate+0x59/0x83
[  574.384031]  [<ffffffff802d7c1f>] ? init_file+0x99/0xbb
[  574.384031]  [<ffffffff802d7deb>] ? alloc_file+0x3e/0x4e
[  574.384031]  [<ffffffff802cbbf7>] shmem_file_setup+0xcf/0x106
[  574.384031]  [<ffffffff802cbc50>] shmem_zero_setup+0x22/0x5e
[  574.384031]  [<ffffffff802bfc92>] mmap_region+0x250/0x438
[  574.384031]  [<ffffffff802282aa>] ? arch_get_unmapped_area_topdown+0x192/0x294
[  574.384031]  [<ffffffff802c047f>] do_mmap_pgoff+0x2fe/0x363
[  574.384031]  [<ffffffff8024978e>] sys32_mmap2+0x7d/0xa7
[  574.384031]  [<ffffffff802481b7>] cstar_dispatch+0x7/0x4b

	Ingo
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[patch] x86: some lock annotations for user copy paths, Nick Piggin, (Wed Sep 10, 4:37 am)
Re: [patch] x86: some lock annotations for user copy paths, Peter Zijlstra, (Wed Sep 10, 4:41 am)
Re: [patch] x86: some lock annotations for user copy paths, Ingo Molnar, (Wed Sep 10, 5:32 am)
Re: [patch] x86: some lock annotations for user copy paths, Peter Zijlstra, (Wed Sep 10, 8:01 am)
[PATCH] sysfs: fix deadlock, Ingo Molnar, (Fri Sep 12, 2:24 am)
Re: [PATCH] sysfs: fix deadlock, Nick Piggin, (Sun Sep 14, 3:02 pm)
[patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, Nick Piggin, (Sun Sep 14, 3:12 pm)
Re: [PATCH] sysfs: fix deadlock, Peter Zijlstra, (Mon Sep 15, 2:15 am)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, Andrew Morton, (Wed Sep 17, 1:14 pm)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, Matt Mackall, (Wed Sep 17, 1:46 pm)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, Jeremy Fitzhardinge, (Thu Sep 18, 12:29 pm)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, Matt Mackall, (Thu Sep 18, 2:11 pm)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, Hugh Dickins, (Sat Sep 20, 9:12 am)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, David Howells, (Mon Sep 22, 7:54 am)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, Nick Piggin, (Mon Sep 22, 10:32 pm)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, David Howells, (Wed Sep 24, 11:18 am)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, Matt Mackall, (Wed Sep 24, 11:29 am)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, David Howells, (Wed Sep 24, 11:56 am)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, Matt Mackall, (Wed Sep 24, 12:11 pm)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, David Howells, (Wed Sep 24, 12:26 pm)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, Hugh Dickins, (Wed Sep 24, 12:29 pm)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, Hugh Dickins, (Wed Sep 24, 12:41 pm)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, Andrew Morton, (Wed Sep 24, 12:47 pm)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, David Howells, (Wed Sep 24, 12:59 pm)
Re: [patch] mm: tiny-shmem fix lor, mmap_sem vs i_mutex, Hugh Dickins, (Wed Sep 24, 4:43 pm)