linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Zach Brown <zach.brown@oracle.com>,
	cmm@us.ibm.com, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org,
	Andy Whitcroft <apw@shadowen.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: [EXT4 set 5][PATCH 1/1] expand inode i_extra_isize to support features in larger inode
Date: Sun, 15 Jul 2007 11:11:09 -0700	[thread overview]
Message-ID: <20070715111109.a2775ae4.akpm@linux-foundation.org> (raw)
In-Reply-To: <1184504543.5284.96.camel@lappy>

On Sun, 15 Jul 2007 15:02:23 +0200 Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, 2007-07-13 at 14:47 -0700, Zach Brown wrote:
> 
> > Peter, do you have any interest in seeing how far we can get
> > at tracking lock_page()?  I'm not holding my breath, but any little bit
> > would probably help.
> 
> Would this be a valid report? 
> 
> ( /me goes hunt a x86_64 unwinder patch that will apply to this tree.
>   These stacktraces are pain )

They are.  lockdep reports are a pain too.  It's still a struggle to
understand wtf they're trying to tell you.  Mabe it's just me.

> =======================================================
> [ INFO: possible circular locking dependency detected ]
> [ 2.6.22-rt3-dirty #34
> -------------------------------------------------------
> mount/1296 is trying to acquire lock:
>  (&ei->truncate_mutex){--..}, at: [<ffffffff802f75e5>] ext3_get_blocks_handle+0x1a4/0x8f7
> 
> but task is already holding lock:
>  (lock_page_0){--..}, at: [<ffffffff80267107>] generic_file_buffered_write+0x1ee/0x646
> 
> which lock already depends on the new lock.
> 
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #1 (lock_page_0){--..}:
>        [<ffffffff80251b26>] __lock_acquire+0xa72/0xc35
>        [<ffffffff802520c9>] lock_acquire+0x48/0x61
>        [<ffffffff80265e22>] add_to_page_cache_lru+0xe/0x23
>        [<ffffffff80265d31>] add_to_page_cache+0x1de/0x2c1
>        [<ffffffff80265e22>] add_to_page_cache_lru+0xe/0x23
>        [<ffffffff80266985>] find_or_create_page+0x4c/0x73
>        [<ffffffff802ae716>] __getblk+0x118/0x23c
>        [<ffffffff802afa91>] __bread+0x6/0x9c
>        [<ffffffff802f382d>] read_block_bitmap+0x34/0x65
>        [<ffffffff802f3e1b>] ext3_free_blocks_sb+0xec/0x3d4
>        [<ffffffff802f4131>] ext3_free_blocks+0x2e/0x61
>        [<ffffffff802f82bc>] ext3_free_data+0xaa/0xda
>        [<ffffffff802f8976>] ext3_truncate+0x4d2/0x84e
>        [<ffffffff8026df5a>] pagevec_lookup+0x17/0x1e
>        [<ffffffff8026e7b1>] truncate_inode_pages_range+0x1f4/0x323
>        [<ffffffff802614b4>] add_preempt_count+0x14/0xe4
>        [<ffffffff80304d13>] journal_stop+0x1fe/0x21d
>        [<ffffffff8027661a>] vmtruncate+0xa2/0xc0
>        [<ffffffff802a292b>] inode_setattr+0x22/0x10a
>        [<ffffffff802f9b51>] ext3_setattr+0x136/0x18f
>        [<ffffffff802a2b1d>] notify_change+0x10a/0x241
>        [<ffffffff802a2b3b>] notify_change+0x128/0x241
>        [<ffffffff8028e35e>] do_truncate+0x56/0x7f
>        [<ffffffff8028e369>] do_truncate+0x61/0x7f
>        [<ffffffff80296278>] get_write_access+0x3f/0x45
>        [<ffffffff802973c7>] may_open+0x193/0x1af
>        [<ffffffff80299869>] open_namei+0x2cb/0x63e
>        [<ffffffff8025718b>] rt_up_read+0x53/0x5c
>        [<ffffffff8056da59>] do_page_fault+0x479/0x7cc
>        [<ffffffff8028dce1>] do_filp_open+0x1c/0x38
>        [<ffffffff8056a4f9>] rt_spin_unlock+0x17/0x47
>        [<ffffffff8028da05>] get_unused_fd+0xf9/0x107
>        [<ffffffff8028dd45>] do_sys_open+0x48/0xd5
>        [<ffffffff8020950e>] system_call+0x7e/0x83
>        [<ffffffffffffffff>] 0xffffffffffffffff

I guess we're doing lock_page() against a blockdev pagecache page here
while holding truncate_mutex against some S_ISREG file.

> -> #0 (&ei->truncate_mutex){--..}:
>        [<ffffffff802503b9>] print_circular_bug_header+0xcc/0xd3
>        [<ffffffff80251a22>] __lock_acquire+0x96e/0xc35
>        [<ffffffff802520c9>] lock_acquire+0x48/0x61
>        [<ffffffff802f75e5>] ext3_get_blocks_handle+0x1a4/0x8f7
>        [<ffffffff8056a6d4>] _mutex_lock+0x26/0x52
>        [<ffffffff802f75e5>] ext3_get_blocks_handle+0x1a4/0x8f7
>        [<ffffffff802504b2>] find_usage_backwards+0xb0/0xd9
>        [<ffffffff802504b2>] find_usage_backwards+0xb0/0xd9
>        [<ffffffff80250d7c>] debug_check_no_locks_freed+0x11d/0x129
>        [<ffffffff80250c33>] trace_hardirqs_on_caller+0x115/0x138
>        [<ffffffff8024efdc>] lockdep_init_map+0xac/0x41f
>        [<ffffffff802614b4>] add_preempt_count+0x14/0xe4
>        [<ffffffff802f8035>] ext3_get_block+0xc2/0xe4
>        [<ffffffff802aeed3>] __block_prepare_write+0x195/0x442
>        [<ffffffff802f7f73>] ext3_get_block+0x0/0xe4
>        [<ffffffff802af19a>] block_prepare_write+0x1a/0x25
>        [<ffffffff802f93e9>] ext3_prepare_write+0xb2/0x17b
>        [<ffffffff802671b1>] generic_file_buffered_write+0x298/0x646
>        [<ffffffff8023944e>] current_fs_time+0x3b/0x40
>        [<ffffffff802614b4>] add_preempt_count+0x14/0xe4
>        [<ffffffff802678ae>] __generic_file_aio_write_nolock+0x34f/0x3b9
>        [<ffffffff8024ed3d>] put_lock_stats+0xe/0x2a
>        [<ffffffff80267964>] generic_file_aio_write+0x4c/0xc4
>        [<ffffffff80267979>] generic_file_aio_write+0x61/0xc4
>        [<ffffffff802fcf18>] ext3_orphan_del+0x53/0x19f
>        [<ffffffff802f5768>] ext3_file_write+0x1c/0x9d
>        [<ffffffff8028ef31>] do_sync_write+0xcc/0x10f
>        [<ffffffff80246f9c>] autoremove_wake_function+0x0/0x2e
>        [<ffffffff8024ecfe>] get_lock_stats+0xe/0x3f
>        [<ffffffff8024ed9a>] lock_release_holdtime+0x41/0x4f
>        [<ffffffff8024ed3d>] put_lock_stats+0xe/0x2a
>        [<ffffffff8028dfb1>] sys_fchmod+0xa3/0xbd
>        [<ffffffff8056a717>] _mutex_unlock+0x17/0x20
>        [<ffffffff8028f6cd>] vfs_write+0xb6/0x148
>        [<ffffffff8028fc61>] sys_write+0x48/0x74
>        [<ffffffff8020950e>] system_call+0x7e/0x83
>        [<ffffffffffffffff>] 0xffffffffffffffff

Here we're taking a file's truncate_mutex while holding lock_page() against
one of its pages.  This is the correct lock ranking, I suppose.

This is one of those fairly common cross-inode notabugs, I suspect.

  parent reply	other threads:[~2007-07-15 18:11 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-01  7:38 [EXT4 set 5][PATCH 1/1] expand inode i_extra_isize to support features in larger inode Mingming Cao
2007-07-10 23:32 ` Andrew Morton
2007-07-11 12:10   ` Andreas Dilger
2007-07-11 17:34     ` Andrew Morton
2007-07-11 19:24       ` Kalpak Shah
2007-07-12 12:14   ` Kalpak Shah
2007-07-13  9:05   ` Andrew Morton
2007-07-13 13:33     ` Peter Zijlstra
2007-07-13 15:43       ` Andreas Dilger
2007-07-13 19:12       ` Andrew Morton
2007-07-13 21:47         ` Zach Brown
2007-07-14  7:43           ` Peter Zijlstra
2007-07-15 10:21           ` Peter Zijlstra
2007-07-15 13:02           ` Peter Zijlstra
2007-07-15 13:14             ` Peter Zijlstra
2007-07-15 18:11             ` Andrew Morton [this message]
2007-07-15 19:21               ` Peter Zijlstra
2007-07-15 19:59                 ` Andrew Morton
2007-07-15 20:13                   ` Peter Zijlstra
2007-07-13 16:12     ` Andreas Dilger
2007-07-16 23:52     ` Mingming Cao
2007-07-17  0:06       ` Andreas Dilger
2007-07-17  0:24         ` Mingming Cao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070715111109.a2775ae4.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=apw@shadowen.org \
    --cc=cmm@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=zach.brown@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).