lkml.org 
[lkml]   [2011]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: hugetlb locking bug.
    Hmm. Adding the hugetlbfs/lockdep people to the cc.

    This _looks_ like the same kind of false positive we've had with some
    other cases: we're taking the i_mutex lock only dor directory inodes
    (for the readdir) and we take the i_mmap lock only for non-directory
    inodes, so you can't actually get any real circular locking issues.

    So yes, we do mix the order of i_mmap_sem and i_mutex, but it's
    conceptually two "different" kinds of i_mutex that just happen to
    share a name.

    And I really thought we annotated it as such with different
    "lockdep_set_class()" cases (ie the whole

    lockdep_set_class(&inode->i_mutex,&type->i_mutex_dir_key);

    for the S_ISDIR case in unlock_new_inode().

    Can somebody more alert than me see why this lockdep issue still
    triggers with hugetlbfs?

    Linus

    On Fri, Apr 15, 2011 at 1:16 PM, Dave Jones <davej@redhat.com> wrote:
    > Just hit this lockdep report..
    >
    >        Dave
    >
    >  =======================================================
    >  [ INFO: possible circular locking dependency detected ]
    >  2.6.39-rc3+ #3
    >  -------------------------------------------------------
    >  trinity/11299 is trying to acquire lock:
    >  (&sb->s_type->i_mutex_key#18){+.+.+.}, at: [<ffffffff811ebfec>] hugetlbfs_file_mmap+0x7f/0x10d
    >
    >  but task is already holding lock:
    >  (&mm->mmap_sem){++++++}, at: [<ffffffff81109097>] sys_mmap_pgoff+0xf8/0x16a
    >
    >  which lock already depends on the new lock.
    >
    >
    >  the existing dependency chain (in reverse order) is:
    >
    >  -> #1 (&mm->mmap_sem){++++++}:
    >        [<ffffffff81086c59>] lock_acquire+0xd0/0xfb
    >        [<ffffffff81100cd0>] might_fault+0x89/0xac
    >        [<ffffffff8114159b>] filldir+0x6f/0xc7
    >        [<ffffffff81150075>] dcache_readdir+0x67/0x204
    >        [<ffffffff811417ed>] vfs_readdir+0x78/0xb1
    >        [<ffffffff8114190c>] sys_getdents+0x7e/0xd1
    >        [<ffffffff814c22c2>] system_call_fastpath+0x16/0x1b
    >
    >  -> #0 (&sb->s_type->i_mutex_key#18){+.+.+.}:
    >        [<ffffffff810864e6>] __lock_acquire+0x99e/0xc81
    >        [<ffffffff81086c59>] lock_acquire+0xd0/0xfb
    >        [<ffffffff814b9d00>] __mutex_lock_common+0x4c/0x35b
    >        [<ffffffff814ba0d3>] mutex_lock_nested+0x3e/0x43
    >        [<ffffffff811ebfec>] hugetlbfs_file_mmap+0x7f/0x10d
    >        [<ffffffff81108ac8>] mmap_region+0x26d/0x446
    >        [<ffffffff81108f45>] do_mmap_pgoff+0x2a4/0x2fe
    >        [<ffffffff811090b7>] sys_mmap_pgoff+0x118/0x16a
    >        [<ffffffff8100c56c>] sys_mmap+0x22/0x24
    >        [<ffffffff814c22c2>] system_call_fastpath+0x16/0x1b
    >
    >  other info that might help us debug this:
    >
    >  1 lock held by trinity/11299:
    >  #0:  (&mm->mmap_sem){++++++}, at: [<ffffffff81109097>] sys_mmap_pgoff+0xf8/0x16a
    >
    >  stack backtrace:
    >  Pid: 11299, comm: trinity Not tainted 2.6.39-rc3+ #3
    >  Call Trace:
    >  [<ffffffff814b1126>] print_circular_bug+0xa6/0xb5
    >  [<ffffffff810864e6>] __lock_acquire+0x99e/0xc81
    >  [<ffffffff811ebfec>] ? hugetlbfs_file_mmap+0x7f/0x10d
    >  [<ffffffff81086c59>] lock_acquire+0xd0/0xfb
    >  [<ffffffff811ebfec>] ? hugetlbfs_file_mmap+0x7f/0x10d
    >  [<ffffffff811ebfec>] ? hugetlbfs_file_mmap+0x7f/0x10d
    >  [<ffffffff814b9d00>] __mutex_lock_common+0x4c/0x35b
    >  [<ffffffff811ebfec>] ? hugetlbfs_file_mmap+0x7f/0x10d
    >  [<ffffffff814b3ee2>] ? __slab_alloc+0xdb/0x3b7
    >  [<ffffffff81087043>] ? trace_hardirqs_on_caller+0x10b/0x12f
    >  [<ffffffff814b3eeb>] ? __slab_alloc+0xe4/0x3b7
    >  [<ffffffff81108a12>] ? mmap_region+0x1b7/0x446
    >  [<ffffffff814ba0d3>] mutex_lock_nested+0x3e/0x43
    >  [<ffffffff811ebfec>] hugetlbfs_file_mmap+0x7f/0x10d
    >  [<ffffffff81108ac8>] mmap_region+0x26d/0x446
    >  [<ffffffff81108f45>] do_mmap_pgoff+0x2a4/0x2fe
    >  [<ffffffff811090b7>] sys_mmap_pgoff+0x118/0x16a
    >  [<ffffffff81087043>] ? trace_hardirqs_on_caller+0x10b/0x12f
    >  [<ffffffff8100c56c>] sys_mmap+0x22/0x24
    >  [<ffffffff814c22c2>] system_call_fastpath+0x16/0x1b
    >
    >
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-04-15 22:55    [W:0.027 / U:0.572 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site