xfs
[Top] [All Lists]

Re: xfs: possible irq lock inversion dependency detected

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: xfs: possible irq lock inversion dependency detected
From: Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx>
Date: Thu, 26 Jun 2014 19:03:41 -0400
Cc: Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140626225857.GT9508@dastard>
References: <20140626142004.31b981dc@xxxxxxxxxxxxxxxxxxxxxxx> <20140626225857.GT9508@dastard>
On Fri, 27 Jun 2014 08:58:57 +1000
Dave Chinner <david@xxxxxxxxxxxxx> wrote:

> 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.

No problem. Just figured I'd report it in case it were something new.
I'll just keep ignoring it.

Thanks!
-- 
Jeff Layton <jlayton@xxxxxxxxxxxxxxx>

<Prev in Thread] Current Thread [Next in Thread>