On 4/22/13 7:08 PM, Dave Chinner wrote:
> On Mon, Apr 22, 2013 at 02:59:54PM -0500, Eric Sandeen wrote:
>> On 4/15/13 6:14 PM, Brian Foster wrote:
>>> Thanks for the data in the previous thread:
>>> I'm spinning off a new thread specifically for this because the original
>>> thread is already too large and scattered to track. As Eric stated,
>>> please try to keep data contained in as few messages as possible.
>> Well, it's always simple in the end. It just took a lot of debugging
>> to figure out what was happening - we do appreciate your help with that!
>> We were able to create a local reproducer, and it looks like
>> this patch fixes things:
>> commit aae8a97d3ec30788790d1720b71d76fd8eb44b73
>> Author: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxxxxxxx>
>> Date: Sat Jan 29 18:43:27 2011 +0530
>> fs: Don't allow to create hardlink for deleted file
> Good find Eric - great work on the reproducer script.
> FWIW, can you confirm that a debug kernel assert fails
> with a non-zero link count in xfs_bumplink() with your test case?
> xfs_trans_t *tp,
> xfs_inode_t *ip)
> xfs_trans_ichgtime(tp, ip, XFS_ICHGTIME_CHG);
>>>>>> ASSERT(ip->i_d.di_nlink > 0);
Yep, it does, I put a printk in there when I was testing
and it fired.
Guess we should have tested a debug xfs right off the bat ;)
> If it does, we should consider this a in-memory corruption case and
> return and trigger a shutdown here....
I suppose that makes sense, it'd be a much less cryptic failure for
something that will fail soon anyway.