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: >>> Hi, >>> >>> Thanks for the data in the previous thread: >>> >>> http://oss.sgi.com/archives/xfs/2013-04/msg00327.html >>> >>> 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? > > int > xfs_bumplink( > 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 ;) > ip->i_d.di_nlink++; > inc_nlink(VFS_I(ip)); > > 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. -Eric > Cheers, > > Dave. > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
