Re: XFS regression?

[Andrew Clayton <andrew@digital-domain.net>]

On Thu, 11 Oct 2007 11:01:39 +1000, David Chinner wrote:

> So it's almost certainly pointing at an elevator or driver change, not
> an XFS change.

heh, git bisect begs to differ :)

4c60658e0f4e253cf275f12b7c76bf128515a774 is first bad commit
commit 4c60658e0f4e253cf275f12b7c76bf128515a774
Author: David Chinner <dgc@sgi.com>
Date:   Sat Nov 11 18:05:00 2006 +1100

    [XFS] Prevent a deadlock when xfslogd unpins inodes.
    
    The previous fixes for the use after free in xfs_iunpin left a nasty log
    deadlock when xfslogd unpinned the inode and dropped the last reference to
    the inode. the ->clear_inode() method can issue transactions, and if the
    log was full, the transaction could push on the log and get stuck trying
    to push the inode it was currently unpinning.
    
    To fix this, we provide xfs_iunpin a guarantee that it will always have a
    valid xfs_inode <-> linux inode link or a particular flag will be set on
    the inode. We then use log forces during lookup to ensure transactions are
    completed before we recycle the inode. This ensures that xfs_iunpin will
    never use the linux inode after it is being freed, and any lookup on an
    inode on the reclaim list will wait until it is safe to attach a new linux
    inode to the xfs inode.
    
    SGI-PV: 956832
    SGI-Modid: xfs-linux-melb:xfs-kern:27359a
    
    Signed-off-by: David Chinner <dgc@sgi.com>
    Signed-off-by: Shailendra Tripathi <stripathi@agami.com>
    Signed-off-by: Takenori Nagano <t-nagano@ah.jp.nec.com>
    Signed-off-by: Tim Shimmin <tes@sgi.com>

:040000 040000 1c47ba44bc404456c87c5a493d543a8d30696b88 92319b34585d03c64e53890a80e550b579a0363d M      fs


If you'd like more info, don't hesitate to ask.

> Cheers,
> 
> dave.

Cheers,

Andrew