xfs
[Top] [All Lists]

Re: xfs: possible irq lock inversion dependency detected

To: Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx>
Subject: Re: xfs: possible irq lock inversion dependency detected
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 27 Jun 2014 08:58:57 +1000
Cc: xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140626142004.31b981dc@xxxxxxxxxxxxxxxxxxxxxxx>
References: <20140626142004.31b981dc@xxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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@xxxxxxxxxxxxx

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