public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexander Beregalov <a.beregalov@gmail.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
	Alessio Igor Bogani <abogani@texware.it>,
	Jeff Mahoney <jeffm@suse.com>,
	ReiserFS Development List <reiserfs-devel@vger.kernel.org>,
	Chris Mason <chris.mason@oracle.com>
Subject: Re: [PATCH 0/3] kill-the-BKL/reiserfs: reiserfs fixes
Date: Tue, 14 Apr 2009 08:51:09 +0400	[thread overview]
Message-ID: <20090414045109.GA26908@orion> (raw)
In-Reply-To: <1239680065-25013-1-git-send-email-fweisbec@gmail.com>

On Tue, Apr 14, 2009 at 05:34:22AM +0200, Frederic Weisbecker wrote:
> Ingo,
> 
> This small patchset fixes some deadlocks I've faced after trying
> some pressures with dbench on a reiserfs partition.
> 
> There is still some work pending such as adding some checks to ensure we
> _always_ release the lock before sleeping, as you suggested.
> Also I have to fix a lockdep warning reported by Alessio Igor Bogani.
> And also some optimizations....
> 
> Thanks,
> Frederic.
> 
> Frederic Weisbecker (3):
>   kill-the-BKL/reiserfs: provide a tool to lock only once the write lock
>   kill-the-BKL/reiserfs: lock only once in reiserfs_truncate_file
>   kill-the-BKL/reiserfs: only acquire the write lock once in
>     reiserfs_dirty_inode
> 
>  fs/reiserfs/inode.c         |   10 +++++++---
>  fs/reiserfs/lock.c          |   26 ++++++++++++++++++++++++++
>  fs/reiserfs/super.c         |   15 +++++++++------
>  include/linux/reiserfs_fs.h |    2 ++
>  4 files changed, 44 insertions(+), 9 deletions(-)
> 

Hi

The same test - dbench on reiserfs on loop on sparc64.

[ INFO: possible circular locking dependency detected ]
2.6.30-rc1-00457-gb21597d-dirty #2
-------------------------------------------------------
dbench/2493 is trying to acquire lock:
 (&REISERFS_SB(s)->lock){+.+.+.}, at: [<000000001003f7a8>] reiserfs_write_lock+0x24/0x44 [reiserfs]

but task is already holding lock:
 (&journal->j_flush_mutex){+.+...}, at: [<0000000010036770>] flush_journal_list+0xa0/0x830 [reiserfs]

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&journal->j_flush_mutex){+.+...}:
       [<00000000004775c8>] lock_acquire+0x5c/0x74
       [<00000000006fa73c>] mutex_lock_nested+0x48/0x380
       [<0000000010037314>] kupdate_transactions+0x30/0x328 [reiserfs]
       [<00000000100376d8>] flush_used_journal_lists+0xcc/0xf0 [reiserfs]
       [<0000000010038508>] do_journal_end+0xe0c/0x127c [reiserfs]
       [<0000000010038a00>] journal_end_sync+0x88/0x9c [reiserfs]
       [<0000000010039370>] reiserfs_commit_for_inode+0x180/0x208 [reiserfs]
       [<0000000010013d2c>] reiserfs_sync_file+0x54/0xb8 [reiserfs]
       [<00000000004d5d64>] vfs_fsync+0x6c/0xa0
       [<00000000004d5dc0>] do_fsync+0x28/0x44
       [<00000000004d5e18>] SyS_fsync+0x14/0x28
       [<0000000000406154>] linux_sparc_syscall32+0x34/0x40

-> #0 (&REISERFS_SB(s)->lock){+.+.+.}:
       [<00000000004775c8>] lock_acquire+0x5c/0x74
       [<00000000006fa73c>] mutex_lock_nested+0x48/0x380
       [<000000001003f7a8>] reiserfs_write_lock+0x24/0x44 [reiserfs]
       [<0000000010036b10>] flush_journal_list+0x440/0x830 [reiserfs]
       [<0000000010036c1c>] flush_journal_list+0x54c/0x830 [reiserfs]
       [<00000000100376ec>] flush_used_journal_lists+0xe0/0xf0 [reiserfs]
       [<0000000010038508>] do_journal_end+0xe0c/0x127c [reiserfs]
       [<0000000010038a00>] journal_end_sync+0x88/0x9c [reiserfs]
       [<0000000010039370>] reiserfs_commit_for_inode+0x180/0x208 [reiserfs]
       [<0000000010013d2c>] reiserfs_sync_file+0x54/0xb8 [reiserfs]
       [<00000000004d5d64>] vfs_fsync+0x6c/0xa0
       [<00000000004d5dc0>] do_fsync+0x28/0x44
       [<00000000004d5e18>] SyS_fsync+0x14/0x28
       [<0000000000406154>] linux_sparc_syscall32+0x34/0x40

other info that might help us debug this:

3 locks held by dbench/2493:
 #0:  (&sb->s_type->i_mutex_key#12){+.+.+.}, at: [<00000000004d5d50>] vfs_fsync+0x58/0xa0
 #1:  (&journal->j_mutex){+.+...}, at: [<00000000100377d4>] do_journal_end+0xd8/0x127c [reiserfs]
 #2:  (&journal->j_flush_mutex){+.+...}, at: [<0000000010036770>] flush_journal_list+0xa0/0x830 [reiserfs]

stack backtrace:
Call Trace:
 [00000000004754a4] print_circular_bug_tail+0xfc/0x10c
 [0000000000476d1c] __lock_acquire+0x12f0/0x1b40
 [00000000004775c8] lock_acquire+0x5c/0x74
 [00000000006fa73c] mutex_lock_nested+0x48/0x380
 [000000001003f7a8] reiserfs_write_lock+0x24/0x44 [reiserfs]
 [0000000010036b10] flush_journal_list+0x440/0x830 [reiserfs]
 [0000000010036c1c] flush_journal_list+0x54c/0x830 [reiserfs]
 [00000000100376ec] flush_used_journal_lists+0xe0/0xf0 [reiserfs]
 [0000000010038508] do_journal_end+0xe0c/0x127c [reiserfs]
 [0000000010038a00] journal_end_sync+0x88/0x9c [reiserfs]
 [0000000010039370] reiserfs_commit_for_inode+0x180/0x208 [reiserfs]
 [0000000010013d2c] reiserfs_sync_file+0x54/0xb8 [reiserfs]
 [00000000004d5d64] vfs_fsync+0x6c/0xa0
 [00000000004d5dc0] do_fsync+0x28/0x44
 [00000000004d5e18] SyS_fsync+0x14/0x28
 [0000000000406154] linux_sparc_syscall32+0x34/0x40

  parent reply	other threads:[~2009-04-14  4:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-14  3:34 [PATCH 0/3] kill-the-BKL/reiserfs: reiserfs fixes Frederic Weisbecker
2009-04-14  3:34 ` [PATCH 1/3] kill-the-BKL/reiserfs: provide a tool to lock only once the write lock Frederic Weisbecker
2009-04-14  3:34 ` [PATCH 2/3] kill-the-BKL/reiserfs: lock only once in reiserfs_truncate_file Frederic Weisbecker
2009-04-14  3:34 ` [PATCH 3/3] kill-the-BKL/reiserfs: only acquire the write lock once in reiserfs_dirty_inode Frederic Weisbecker
2009-04-14  4:51 ` Alexander Beregalov [this message]
2009-04-14  9:01   ` [tree] latest kill-the-BKL tree, v12 Ingo Molnar
2009-04-14 10:02     ` Edward Shishkin
2009-04-14 21:32       ` Frederic Weisbecker
2009-04-14 21:27     ` Frederic Weisbecker
2009-04-15 22:58     ` Alexander Beregalov
2009-04-15 23:07       ` Ingo Molnar
2009-04-15 23:13         ` Trond Myklebust
2009-04-15 23:35         ` Frederic Weisbecker
2009-04-16  8:51           ` Ingo Molnar
2009-04-16 14:35             ` Alessio Igor Bogani
2009-04-16 16:40             ` Frederic Weisbecker
2009-04-14 10:00 ` [PATCH 0/3] kill-the-BKL/reiserfs: reiserfs fixes Ingo Molnar

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=20090414045109.GA26908@orion \
    --to=a.beregalov@gmail.com \
    --cc=abogani@texware.it \
    --cc=chris.mason@oracle.com \
    --cc=fweisbec@gmail.com \
    --cc=jeffm@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=reiserfs-devel@vger.kernel.org \
    /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