All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: xfs readdir hang on for-next (3.15.0-rc1)
Date: Mon, 14 Apr 2014 22:57:37 +0200	[thread overview]
Message-ID: <20140414205737.GI26782@laptop.programming.kicks-ass.net> (raw)
In-Reply-To: <20140414190834.GB62307@bfoster.bfoster>

On Mon, Apr 14, 2014 at 03:08:36PM -0400, Brian Foster wrote:
> On Mon, Apr 14, 2014 at 12:43:14PM -0400, Brian Foster wrote:
> > Hi all,
> > 
> > This is a heads up that I'm seeing a blatant readdir hang on the current
> > for-next with selinux enabled. To reproduce, I format a clean fs, mount
> > and attempt an ls.
> > 
> > The problem does not occur with selinux disabled, if I back out the
> > following commit:
> > 
> > 40194ecc6d78 xfs: reinstate the ilock in xfs_readdir
> > 
> > ... or if I remove the locking around xfs_attr_get(), so I suspect this
> > is another instance of a recursive deadlock. I'm getting no output
> > whatsoever in order to confirm this and it also leads to a complete
> > system lockup. It's also interesting that this hasn't been observed
> > until now, given the above commit was introduced in 3.14. So the above
> > commit doesn't appear to be the most recent change that triggers this.
> > 
> > I reproduced on the latest linus tree and do not reproduce on 3.14, so
> > I'm trying to do a bisect to find out what else might have changed to
> > trigger this.
> > 
> 
> This bisected down to:
> 
> commit 6f008e72cd111a119b5d8de8c5438d892aae99eb
> Author: Peter Zijlstra <peterz@infradead.org>
> Date:   Wed Mar 12 13:24:42 2014 +0100
> 
>     locking/mutex: Fix debug checks
> ...
> 
> ... which suggests something down in the mutex debug code. Indeed, the
> problem no longer occurs if I disable kernel debug in my .config. What
> is also interesting is that it didn't return when I reenable
> DEBUG_KERNEL and DEBUG_MUTEXES alone. It does return when I start to
> enable some of the other lock debugging options. FWIW, I also cleared
> out my tree and rebuilt from scratch just to be sure that I didn't have
> anything stale/broken lying around.
> 
> Peter,
> 
> Any insight on this? 

http://lkml.kernel.org/r/tip-a227960fe0cafcc229a8d6bb8b454a3a0b33719d@git.kernel.org

That will make the kernel continue after the lockdep splat. I too see it
on some of my XFS using machines.


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2014-04-14 20:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-14 16:43 xfs readdir hang on for-next (3.15.0-rc1) Brian Foster
2014-04-14 19:08 ` Brian Foster
2014-04-14 20:57   ` Peter Zijlstra [this message]
2014-04-14 21:47     ` Michael L. Semon
2014-04-14 22:06     ` Brian Foster

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=20140414205737.GI26782@laptop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bfoster@redhat.com \
    --cc=xfs@oss.sgi.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 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.