From: Frederic Weisbecker <fweisbec@gmail.com>
To: "Trenton D. Adams" <trenton.d.adams@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Reiserfs <reiserfs-devel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Jeff Mahoney <jeffm@suse.com>,
Chris Mason <chris.mason@oracle.com>, Ingo Molnar <mingo@elte.hu>,
Alexander Beregalov <a.beregalov@gmail.com>
Subject: Re: [PATCH 1/2] kill-the-bkl/reiserfs: acquire the inode mutex safely
Date: Sat, 30 May 2009 15:41:33 +0200 [thread overview]
Message-ID: <20090530134132.GA5969@nowhere> (raw)
In-Reply-To: <9b1675090905292123l7c3de4b6w897e153d60e5a469@mail.gmail.com>
On Fri, May 29, 2009 at 10:23:44PM -0600, Trenton D. Adams wrote:
> On Fri, May 29, 2009 at 9:22 PM, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > On Fri, May 29, 2009 at 09:05:31PM -0600, Trenton D. Adams wrote:
> >> On Sat, May 16, 2009 at 12:02 PM, Frederic Weisbecker
> >> <fweisbec@gmail.com> wrote:
> >> > While searching a pathname, an inode mutex can be acquired
> >> > in do_lookup() which calls reiserfs_lookup() which in turn
> >> > acquires the write lock.
> >> >
> >> > On the other side reiserfs_fill_super() can acquire the write_lock
> >> > and then call reiserfs_lookup_privroot() which can acquire an
> >> > inode mutex (the root of the mount point).
> >> >
> >> > So we theoretically risk an AB - BA lock inversion that could lead
> >> > to a deadlock.
> >> >
> >> > As for other lock dependencies found since the bkl to mutex
> >> > conversion, the fix is to use reiserfs_mutex_lock_safe() which
> >> > drops the lock dependency to the write lock.
> >> >
> >>
> >> I'm curious, did this get applied, and is it related to the following?
> >> I was having these in 2.6.30-rc3. I am now on 2.6.30-rc7 as of
> >> today. I haven't seen them today. But then again, I only seen this
> >> happen one time.
> >
> >
> > Hi,
> >
> > No, may be it will come for 2.6.31 but for now it is not merged so
> > it's not related.
> >
> > If you see such warning anymore, don't hesitate to tell about
> > it!
> >
> > Thanks!
> >
>
> I was trying to imply that the patch might fix the problem I saw, not
> that it was the cause. I only though that because it mentioned a
> potential deadlock, and it seems like that is what the problem I saw
> was.
Ah ok. No it's part of a tree which reworks the reiserfs locking scheme
by removing the old one based on the legacy and obsolete bkl (big kernel
lock). In this tree I had to fix several deadlocks or at least unsafe
lock states because the bkl is converted into a mutex and some new lock
dependencies were borned after that. But these issues had nothing
to deal with upstream problems.
BTW, would you be interested in giving a try with this reiserfs bkl
removal tree? I really lack testing and feedbacks from users.
Thanks!
Frederic.
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Frederic Weisbecker <fweisbec@gmail.com>
To: "Trenton D. Adams" <trenton.d.adams@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Reiserfs <reiserfs-devel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Jeff Mahoney <jeffm@suse.com>,
Chris Mason <chris.mason@oracle.com>, Ingo Molnar <mingo@elte.hu>,
Alexander Beregalov <a.beregalov@gmail.com>
Subject: Re: [PATCH 1/2] kill-the-bkl/reiserfs: acquire the inode mutex safely
Date: Sat, 30 May 2009 15:41:33 +0200 [thread overview]
Message-ID: <20090530134132.GA5969@nowhere> (raw)
In-Reply-To: <9b1675090905292123l7c3de4b6w897e153d60e5a469@mail.gmail.com>
On Fri, May 29, 2009 at 10:23:44PM -0600, Trenton D. Adams wrote:
> On Fri, May 29, 2009 at 9:22 PM, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > On Fri, May 29, 2009 at 09:05:31PM -0600, Trenton D. Adams wrote:
> >> On Sat, May 16, 2009 at 12:02 PM, Frederic Weisbecker
> >> <fweisbec@gmail.com> wrote:
> >> > While searching a pathname, an inode mutex can be acquired
> >> > in do_lookup() which calls reiserfs_lookup() which in turn
> >> > acquires the write lock.
> >> >
> >> > On the other side reiserfs_fill_super() can acquire the write_lock
> >> > and then call reiserfs_lookup_privroot() which can acquire an
> >> > inode mutex (the root of the mount point).
> >> >
> >> > So we theoretically risk an AB - BA lock inversion that could lead
> >> > to a deadlock.
> >> >
> >> > As for other lock dependencies found since the bkl to mutex
> >> > conversion, the fix is to use reiserfs_mutex_lock_safe() which
> >> > drops the lock dependency to the write lock.
> >> >
> >>
> >> I'm curious, did this get applied, and is it related to the following?
> >> I was having these in 2.6.30-rc3. I am now on 2.6.30-rc7 as of
> >> today. I haven't seen them today. But then again, I only seen this
> >> happen one time.
> >
> >
> > Hi,
> >
> > No, may be it will come for 2.6.31 but for now it is not merged so
> > it's not related.
> >
> > If you see such warning anymore, don't hesitate to tell about
> > it!
> >
> > Thanks!
> >
>
> I was trying to imply that the patch might fix the problem I saw, not
> that it was the cause. I only though that because it mentioned a
> potential deadlock, and it seems like that is what the problem I saw
> was.
Ah ok. No it's part of a tree which reworks the reiserfs locking scheme
by removing the old one based on the legacy and obsolete bkl (big kernel
lock). In this tree I had to fix several deadlocks or at least unsafe
lock states because the bkl is converted into a mutex and some new lock
dependencies were borned after that. But these issues had nothing
to deal with upstream problems.
BTW, would you be interested in giving a try with this reiserfs bkl
removal tree? I really lack testing and feedbacks from users.
Thanks!
Frederic.
next prev parent reply other threads:[~2009-05-30 13:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-16 18:02 [PATCH 0/2] kill-the-bkl/reiserfs: rebase against -rc6, fixes Frederic Weisbecker
2009-05-16 18:02 ` [PATCH 1/2] kill-the-bkl/reiserfs: acquire the inode mutex safely Frederic Weisbecker
2009-05-30 3:05 ` Trenton D. Adams
2009-05-30 3:22 ` Frederic Weisbecker
2009-05-30 4:23 ` Trenton D. Adams
2009-05-30 4:23 ` Trenton D. Adams
2009-05-30 13:41 ` Frederic Weisbecker [this message]
2009-05-30 13:41 ` Frederic Weisbecker
2009-05-30 18:07 ` Trenton D. Adams
2009-05-30 18:07 ` Trenton D. Adams
2009-06-05 18:26 ` Jeff Mahoney
2009-06-05 19:06 ` Trenton D. Adams
2009-06-05 19:06 ` Trenton D. Adams
2009-06-05 19:30 ` Jeff Mahoney
2009-06-05 19:57 ` Trenton D. Adams
2009-06-05 19:57 ` Trenton D. Adams
2009-06-11 0:42 ` Trenton D. Adams
2009-05-16 18:02 ` [PATCH 2/2] kill-the-bkl/reiserfs: move the concurrent tree accesses checks per superblock 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=20090530134132.GA5969@nowhere \
--to=fweisbec@gmail.com \
--cc=a.beregalov@gmail.com \
--cc=chris.mason@oracle.com \
--cc=jeffm@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=reiserfs-devel@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=trenton.d.adams@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.