Bug 735206 - possible circular locking dependency detected
Summary: possible circular locking dependency detected
Keywords:
Status: CLOSED DUPLICATE of bug 730998
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 16
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-01 19:48 UTC by Albert Strasheim
Modified: 2011-09-01 19:51 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-01 19:51:51 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Albert Strasheim 2011-09-01 19:48:40 UTC
Description of problem:

[ 1773.547262] =======================================================
[ 1773.555610] [ INFO: possible circular locking dependency detected ]
[ 1773.562162] 3.1.0-0.rc3.git0.0.fc16.x86_64 #1
[ 1773.566802] -------------------------------------------------------
[ 1773.573365] disktest/6751 is trying to acquire lock:
[ 1773.578613]  (&sb->s_type->i_mutex_key#15){+.+.+.}, at: [<ffffffff811e59d0>] hugetlbfs_file_mmap+0x82/0x10a
[ 1773.589216]
[ 1773.589218] but task is already holding lock:
[ 1773.595650]  (&mm->mmap_sem){++++++}, at: [<ffffffff811181d1>] sys_mmap_pgoff+0xf8/0x16a
[ 1773.604497]
[ 1773.604499] which lock already depends on the new lock.
[ 1773.604500]
[ 1773.613572]
[ 1773.613575] the existing dependency chain (in reverse order) is:
[ 1773.621631]
[ 1773.621632] -> #1 (&mm->mmap_sem){++++++}:
[ 1773.628004]        [<ffffffff8108eff1>] lock_acquire+0xf3/0x13e
[ 1773.634282]        [<ffffffff8110fbd7>] might_fault+0x89/0xac
[ 1773.640393]        [<ffffffff81151cd2>] filldir64+0x7f/0xcd
[ 1773.646391]        [<ffffffff81160635>] dcache_readdir+0x64/0x1fc
[ 1773.652970]        [<ffffffff81151e50>] vfs_readdir+0x7b/0xb4
[ 1773.659193]        [<ffffffff81152040>] sys_getdents64+0x7e/0xca
[ 1773.665691]        [<ffffffff8150b082>] system_call_fastpath+0x16/0x1b
[ 1773.672720]
[ 1773.672721] -> #0 (&sb->s_type->i_mutex_key#15){+.+.+.}:
[ 1773.680531]        [<ffffffff8108e81e>] __lock_acquire+0xa1a/0xcf7
[ 1773.687076]        [<ffffffff8108eff1>] lock_acquire+0xf3/0x13e
[ 1773.693368]        [<ffffffff815025db>] __mutex_lock_common+0x5d/0x39a
[ 1773.700256]        [<ffffffff81502a27>] mutex_lock_nested+0x40/0x45
[ 1773.706887]        [<ffffffff811e59d0>] hugetlbfs_file_mmap+0x82/0x10a
[ 1773.713783]        [<ffffffff81117bdc>] mmap_region+0x274/0x46b
[ 1773.720069]        [<ffffffff8111807f>] do_mmap_pgoff+0x2ac/0x306
[ 1773.726524]        [<ffffffff811181f1>] sys_mmap_pgoff+0x118/0x16a
[ 1773.733085]        [<ffffffff81012880>] sys_mmap+0x22/0x24
[ 1773.738937]        [<ffffffff8150b082>] system_call_fastpath+0x16/0x1b
[ 1773.745835]
[ 1773.745837] other info that might help us debug this:
[ 1773.745838]
[ 1773.754711]  Possible unsafe locking scenario:
[ 1773.754713]
[ 1773.761227]        CPU0                    CPU1
[ 1773.766051]        ----                    ----
[ 1773.770868]   lock(&mm->mmap_sem);
[ 1773.774701]                                lock(&sb->s_type->i_mutex_key);
[ 1773.782013]                                lock(&mm->mmap_sem);
[ 1773.788360]   lock(&sb->s_type->i_mutex_key);
[ 1773.793156]
[ 1773.793158]  *** DEADLOCK ***
[ 1773.793159]
[ 1773.805829] 1 lock held by disktest/6751:
[ 1773.810124]  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff811181d1>] sys_mmap_pgoff+0xf8/0x16a
[ 1773.819450]
[ 1773.819452] stack backtrace:
[ 1773.824414] Pid: 6751, comm: disktest Tainted: G        W   3.1.0-0.rc3.git0.0.fc16.x86_64 #1
[ 1773.833445] Call Trace:
[ 1773.836195]  [<ffffffff814f9b74>] print_circular_bug+0x1f8/0x209
[ 1773.842503]  [<ffffffff8108e81e>] __lock_acquire+0xa1a/0xcf7
[ 1773.848453]  [<ffffffff81131091>] ? deactivate_slab+0x28f/0x2b5
[ 1773.854668]  [<ffffffff811e59d0>] ? hugetlbfs_file_mmap+0x82/0x10a
[ 1773.861138]  [<ffffffff8108eff1>] lock_acquire+0xf3/0x13e
[ 1773.866841]  [<ffffffff811e59d0>] ? hugetlbfs_file_mmap+0x82/0x10a
[ 1773.873312]  [<ffffffff811e59d0>] ? hugetlbfs_file_mmap+0x82/0x10a
[ 1773.879787]  [<ffffffff815025db>] __mutex_lock_common+0x5d/0x39a
[ 1773.886085]  [<ffffffff811e59d0>] ? hugetlbfs_file_mmap+0x82/0x10a
[ 1773.892566]  [<ffffffff81117b11>] ? mmap_region+0x1a9/0x46b
[ 1773.898427]  [<ffffffff81502a27>] mutex_lock_nested+0x40/0x45
[ 1773.904461]  [<ffffffff811e59d0>] hugetlbfs_file_mmap+0x82/0x10a
[ 1773.910763]  [<ffffffff81117bdc>] mmap_region+0x274/0x46b
[ 1773.916447]  [<ffffffff8111807f>] do_mmap_pgoff+0x2ac/0x306
[ 1773.922319]  [<ffffffff811181f1>] sys_mmap_pgoff+0x118/0x16a
[ 1773.928262]  [<ffffffff8108f439>] ? trace_hardirqs_on_caller+0x121/0x158
[ 1773.935256]  [<ffffffff812536fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 1773.941980]  [<ffffffff81012880>] sys_mmap+0x22/0x24
[ 1773.947252]  [<ffffffff8150b082>] system_call_fastpath+0x16/0x1b

Version-Release number of selected component (if applicable):

kernel-3.1.0-0.rc3.git0.0.fc16.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Lots of disk I/O to and from blocks mmaped in /dev/hugepages.
  
Additional info:

Comment 1 Josh Boyer 2011-09-01 19:51:51 UTC

*** This bug has been marked as a duplicate of bug 730998 ***


Note You need to log in before you can comment on or make changes to this bug.