All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@fusionio.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Mike Galbraith <efault@gmx.de>,
	"linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: 3.4.4-rt13: btrfs + xfstests 006 = BOOM.. and a bonus rt_mutex deadlock report for absolutely free!
Date: Fri, 13 Jul 2012 06:47:41 -0400	[thread overview]
Message-ID: <20120713104741.GF30128@shiny> (raw)
In-Reply-To: <alpine.LFD.2.02.1207131223240.32033@ionos>

On Fri, Jul 13, 2012 at 04:26:26AM -0600, Thomas Gleixner wrote:
> On Fri, 13 Jul 2012, Mike Galbraith wrote:
> > On Fri, 2012-07-13 at 11:52 +0200, Thomas Gleixner wrote: 
> > > On Fri, 13 Jul 2012, Mike Galbraith wrote:
> > > > On Thu, 2012-07-12 at 15:31 +0200, Thomas Gleixner wrote: 
> > > > > Bingo, that makes it more likely that this is caused by copying w/o
> > > > > initializing the lock and then freeing the original structure.
> > > > > 
> > > > > A quick check for memcpy finds that __btrfs_close_devices() does a
> > > > > memcpy of btrfs_device structs w/o initializing the lock in the new
> > > > > copy, but I have no idea whether that's the place we are looking for.
> > > > 
> > > > Thanks a bunch Thomas.  I doubt I would have ever figured out that lala
> > > > land resulted from _copying_ a lock.  That's one I won't be forgetting
> > > > any time soon.  Box not only survived a few thousand xfstests 006 runs,
> > > > dbench seemed disinterested in deadlocking virgin 3.0-rt.
> > > 
> > > Cute. It think that the lock copying caused the deadlock problem as
> > > the list pointed to the wrong place, so we might have ended up with
> > > following down the wrong chain when walking the list as long as the
> > > original struct was not freed. That beast is freed under RCU so there
> > > could be a rcu read side critical section fiddling with the old lock
> > > and cause utter confusion.
> > 
> > Virgin 3.0-rt appears to really be solid.  But then it doesn't have
> > pesky rwlocks.
> 
> Ah. So 3.0 is not having those rwlock thingies. Bummer.
>  
> > > /me goes and writes a nastigram^W proper changelog
> > > 
> > > > btrfs still locks up in my enterprise kernel, so I suppose I had better
> > > > plug your fix into 3.4-rt and see what happens, and go beat hell out of
> > > > virgin 3.0-rt again to be sure box really really survives dbench.
> > > 
> > > A test against 3.4-rt sans enterprise mess might be nice as well.
> > 
> > Enterprise is 3.0-stable with um 555 btrfs patches (oh dear).
> > 
> > Virgin 3.4-rt and 3.2-rt deadlock gripe.  Enterprise doesn't gripe, but
> > deadlocks, so I have another adventure in my future even if I figure out
> > wth to do about rwlocks.
> 
> Hrmpf. /me goes to stare into fs/btrfs/ some more.

Please post the deadlocks here, I'll help ;)

-chris

  reply	other threads:[~2012-07-13 10:47 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-12  5:47 3.4.4-rt13: btrfs + xfstests 006 = BOOM.. and a bonus rt_mutex deadlock report for absolutely free! Mike Galbraith
2012-07-12  8:44 ` Mike Galbraith
2012-07-12  9:53   ` Mike Galbraith
2012-07-12 11:43     ` Thomas Gleixner
2012-07-12 11:57       ` Mike Galbraith
2012-07-12 13:31         ` Thomas Gleixner
2012-07-12 13:37           ` Mike Galbraith
2012-07-12 13:43             ` Thomas Gleixner
2012-07-12 13:48               ` Mike Galbraith
2012-07-12 13:51                 ` Mike Galbraith
2012-07-13  6:31           ` Mike Galbraith
2012-07-13  9:52             ` Thomas Gleixner
2012-07-13 10:14               ` Mike Galbraith
2012-07-13 10:26                 ` Thomas Gleixner
2012-07-13 10:47                   ` Chris Mason [this message]
2012-07-13 12:50                     ` Mike Galbraith
2012-07-12 11:07 ` Thomas Gleixner
2012-07-12 17:09   ` Chris Mason
2012-07-13 10:04     ` Thomas Gleixner
2012-07-13 12:50 ` Chris Mason
2012-07-13 14:47   ` Thomas Gleixner
2012-07-14 10:14   ` Mike Galbraith
2012-07-15 17:56     ` Chris Mason
2012-07-16  2:02       ` Mike Galbraith
2012-07-16 16:02         ` Steven Rostedt
2012-07-16 16:26           ` Mike Galbraith
2012-07-16 16:35             ` Chris Mason
2012-07-16 16:36             ` Mike Galbraith
2012-07-16 17:03               ` Steven Rostedt
2012-07-17  4:18                 ` Mike Galbraith
2012-07-17  4:27                   ` Steven Rostedt
2012-07-17  4:34                     ` Steven Rostedt
2012-07-17  4:46                       ` Mike Galbraith
2012-07-17  4:44                     ` Mike Galbraith
2012-07-17 12:54                   ` Mike Galbraith
2012-07-16 10:55     ` Mike Galbraith
2012-07-16 15:43       ` Chris Mason
2012-07-16 16:16         ` Mike Galbraith
2012-07-14 13:38   ` Mike Galbraith

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=20120713104741.GF30128@shiny \
    --to=chris.mason@fusionio.com \
    --cc=efault@gmx.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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.