reiserfs-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Alexander Beregalov <a.beregalov@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Reiserfs <reiserfs-devel@vger.kernel.org>
Subject: Re: [PATCH 0/4] kill-the-bkl/reiserfs: fix some lock dependency inversions
Date: Mon, 14 Sep 2009 23:50:13 +0200	[thread overview]
Message-ID: <20090914215011.GM6045@nowhere> (raw)
In-Reply-To: <a4423d670909141433g18659aay6e177b1302e5b4a0@mail.gmail.com>

On Tue, Sep 15, 2009 at 01:33:42AM +0400, Alexander Beregalov wrote:
> > Hi Alexander,
> >
> > It should be fixed now, still in the following tree:
> 
> Hi!
> Another one, similar:
> It is v2.6.31-3123-g99bc470 plus your 805031859(kill-the-bkl/reiserfs:
> panic in case of lock imbalance), UP.
> 
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.31-03149-gdcc030a #1
> -------------------------------------------------------
> udevadm/716 is trying to acquire lock:
>  (&mm->mmap_sem){++++++}, at: [<c107249a>] might_fault+0x4a/0xa0



I hate this mm->mmap_sem....



> 
> but task is already holding lock:
>  (sysfs_mutex){+.+.+.}, at: [<c10cb9aa>] sysfs_readdir+0x5a/0x200
> 
> which lock already depends on the new lock.



This is really weird. This is two externals locks from reiserfs.
I guess I created this dependency somewhere, but how...

Anyway, someone reported a similar bug with this tree some months ago,
I've even met it once but could never be able to reproduce it anymore.

I'll try to find out. Thanks!


  reply	other threads:[~2009-09-14 21:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-25  2:32 [PATCH 0/4] kill-the-bkl/reiserfs: fix some lock dependency inversions Frederic Weisbecker
2009-08-25  2:32 ` [PATCH 1/4] kill-the-bkl/reiserfs: fix "reiserfs lock" / "inode mutex" lock inversion dependency Frederic Weisbecker
2009-08-25  2:32 ` [PATCH 2/4] kill-the-bkl/reiserfs: fix recursive reiserfs lock in reiserfs_mkdir() Frederic Weisbecker
2009-08-25  2:32 ` [PATCH 3/4] kill-the-bkl/reiserfs: fix recursive reiserfs write lock in reiserfs_commit_write() Frederic Weisbecker
2009-08-25  2:32 ` [PATCH 4/4] kill-the-bkl/reiserfs: panic in case of lock imbalance Frederic Weisbecker
2009-08-26 20:13 ` [PATCH 0/4] kill-the-bkl/reiserfs: fix some lock dependency inversions Alexander Beregalov
2009-09-01 22:16   ` Frederic Weisbecker
2009-09-14 20:37   ` Frederic Weisbecker
2009-09-14 21:33     ` Alexander Beregalov
2009-09-14 21:50       ` Frederic Weisbecker [this message]
2009-09-16 20:37       ` Frederic Weisbecker
2009-09-16 23:37         ` Alexander Beregalov
2009-09-17  5:06           ` [PATCH] kill-the-bkl/reiserfs: Fix induced mm->mmap_sem to sysfs_mutex dependency Frederic Weisbecker
2009-09-22 13:55             ` Alexander Beregalov
2009-09-29  7:46               ` Frederic Weisbecker
2009-09-29 10:22                 ` Alexander Beregalov
2009-10-05 18:12                   ` [PATCH] kill-the-bkl/reiserfs: fix reiserfs lock to cpu_add_remove_lock dependency Frederic Weisbecker

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=20090914215011.GM6045@nowhere \
    --to=fweisbec@gmail.com \
    --cc=a.beregalov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).