From: Dave Chinner <david@fromorbit.com>
To: Jeff Layton <jeff.layton@primarydata.com>
Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: xfs: possible irq lock inversion dependency detected
Date: Fri, 27 Jun 2014 08:58:57 +1000 [thread overview]
Message-ID: <20140626225857.GT9508@dastard> (raw)
In-Reply-To: <20140626142004.31b981dc@tlielax.poochiereds.net>
On Thu, Jun 26, 2014 at 02:20:04PM -0400, Jeff Layton wrote:
> While testing some knfsd patches on XFS today, I got this lockdep
> splatter. The kernel is a stock -rc2 kernel with a pile of knfsd
> patches on top. There are a couple of others in other areas, but
> nothing that would affect this.
>
> Nothing crashed or seems to be hung, so I'm not sure if it's a real
> problem or not...
Known false positive. the problem is that lockdep is too stupid to
realise you can't mmap a directory inode, but it sees unused
directory inodes from memory reclaim in page faults (i.e. under the
mmap_sem) and so therefore thinks that taking a page fault in
readdir() while holding a directory inode lock on a referenced
directory inode will deadlock....
Teaching lockdep the intricacies of locking heirarchies is difficult
and painful. Fixing this one (and all the other stupidities lockdep
reports because of this) can't be done through annotations - it
requires rewriting a bunch of directory code to use different locks.
And, well, it ain't actually broken right now and there's other more
important issues to be fixed, so unless someone else beats me to
rewriting the readdir readahead code, lockdep is going to remain
unhappy about XFS.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-06-26 22:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-26 18:20 xfs: possible irq lock inversion dependency detected Jeff Layton
2014-06-26 22:58 ` Dave Chinner [this message]
2014-06-26 23:03 ` Jeff Layton
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=20140626225857.GT9508@dastard \
--to=david@fromorbit.com \
--cc=jeff.layton@primarydata.com \
--cc=linux-fsdevel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox