xfs
[Top] [All Lists]

Re: XFS reclaim lock order bug

To: Nick Piggin <npiggin@xxxxxxxxx>
Subject: Re: XFS reclaim lock order bug
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 24 Nov 2010 08:12:58 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20101123121802.GA4785@amd>
References: <20101123121802.GA4785@amd>
User-agent: Mutt/1.5.20 (2009-06-14)
On Tue, Nov 23, 2010 at 11:18:02PM +1100, Nick Piggin wrote:
> Hi,
> 
> IIRC I've reported this before. Perhaps it is a false positive, but even
> so it is still annoying that it triggers and turns off lockdep for
> subsequent debugging.
> 
> Any chance it can get fixed or properly annotated?

It is supposed to be handled by the re-initialisation of the
ip->i_iolock in ->evict_inode (xfs_fs_evict_inode). An inode found
in the reclaim state must have passed through this reinitialisation,
so from a lockdep perspective the iolock in the vfs path is a
different context to the iolock in the reclaim path. That fixed all
the non-reclaim state related lockdep false positives, so Perhaps
there is an issue with the lockdep reclaim state checking that does
not interact well with re-initialised lock contexts?

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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