Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756034Ab2BQAJB (ORCPT ); Thu, 16 Feb 2012 19:09:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:62811 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754740Ab2BQAI7 (ORCPT ); Thu, 16 Feb 2012 19:08:59 -0500 Date: Thu, 16 Feb 2012 19:08:57 -0500 From: Dave Jones To: Josh Boyer Cc: Linux Kernel Subject: hugetlbfs lockdep spew revisited. Message-ID: <20120217000856.GA13112@redhat.com> Mail-Followup-To: Dave Jones , Josh Boyer , Linux Kernel MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3580 Lines: 89 Remember this ? https://lkml.org/lkml/2011/4/15/272 Josh took a stab at fixing it in e096d0c7e2e4e5893792db865dd065ac73cf1f00, but it seems to still be there. Dave ====================================================== [ INFO: possible circular locking dependency detected ] 3.3.0-rc3+ #2 Not tainted ------------------------------------------------------- trinity/30663 is trying to acquire lock: (&sb->s_type->i_mutex_key#18){+.+...}, at: [] hugetlbfs_file_mmap+0x89/0x140 but task is already holding lock: (&mm->mmap_sem){++++++}, at: [] sys_mmap_pgoff+0x1d7/0x230 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&mm->mmap_sem){++++++}: [] lock_acquire+0x9d/0x220 [] might_fault+0x80/0xb0 [] filldir+0x77/0xe0 [] dcache_readdir+0x5e/0x220 [] vfs_readdir+0xb8/0xf0 [] sys_getdents+0x89/0x100 [] system_call_fastpath+0x16/0x1b -> #0 (&sb->s_type->i_mutex_key#18){+.+...}: [] __lock_acquire+0x1bf8/0x1c20 [] lock_acquire+0x9d/0x220 [] __mutex_lock_common+0x59/0x500 [] mutex_lock_nested+0x44/0x50 [] hugetlbfs_file_mmap+0x89/0x140 [] mmap_region+0x369/0x4f0 [] do_mmap_pgoff+0x36f/0x390 [] sys_mmap_pgoff+0x1f7/0x230 [] sys_mmap+0x22/0x30 [] system_call_fastpath+0x16/0x1b other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_sem); lock(&sb->s_type->i_mutex_key#18); lock(&mm->mmap_sem); lock(&sb->s_type->i_mutex_key#18); *** DEADLOCK *** 1 lock held by trinity/30663: #0: (&mm->mmap_sem){++++++}, at: [] sys_mmap_pgoff+0x1d7/0x230 stack backtrace: Pid: 30663, comm: trinity Not tainted 3.3.0-rc3+ #2 Call Trace: [] print_circular_bug+0x1fb/0x20c [] __lock_acquire+0x1bf8/0x1c20 [] ? sub_preempt_count+0x9d/0xd0 [] ? deactivate_slab+0x54c/0x5f0 [] lock_acquire+0x9d/0x220 [] ? hugetlbfs_file_mmap+0x89/0x140 [] ? trace_hardirqs_on_caller+0x10d/0x1a0 [] __mutex_lock_common+0x59/0x500 [] ? hugetlbfs_file_mmap+0x89/0x140 [] ? mmap_region+0x2a5/0x4f0 [] ? hugetlbfs_file_mmap+0x89/0x140 [] mutex_lock_nested+0x44/0x50 [] hugetlbfs_file_mmap+0x89/0x140 [] mmap_region+0x369/0x4f0 [] ? file_map_prot_check+0xaa/0xe0 [] do_mmap_pgoff+0x36f/0x390 [] ? sys_mmap_pgoff+0x1d7/0x230 [] sys_mmap_pgoff+0x1f7/0x230 [] ? trace_hardirqs_on_caller+0x10d/0x1a0 [] sys_mmap+0x22/0x30 [] 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/