On Fri, Oct 13, 2017 at 06:08:39AM -0400, Brian Foster wrote: > On Fri, Oct 13, 2017 at 01:46:05PM +0800, Eryu Guan wrote: > > On Thu, Oct 12, 2017 at 07:36:27AM -0400, Brian Foster wrote: > > > XFS had a bug that resulted in an unexpected NULL buffer during > > > unlink of an inode with a multi-level attr fork tree. This occurred > > > due to a stale reference to content in a released/reclaimed buffer. > > > > > > Use the XFS buffer LRU reference count error injection tag to > > > recreate the conditions for the bug. Create a file with a > > > multi-level attr fork tree and then unlink it with buffer caching > > > disabled. > > > > > > Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx> > > > --- > > > > > > Note that this test depends on a pending[1] XFS error injection tag. > > > > > > Brian > > > > > > [1] https://marc.info/?l=linux-xfs&m=150765408521029&w=2 > > > > I ran this test with above patch applied (v4.14-rc4 based), and kernel > > crashed as expected. Then cherry-pick commit f35c5e10c6ed ("xfs: reinit > > btree pointer on attr tree inactivation walk") and test passed. So test > > looks good to me, just that I added 'dangerous' group and referenced the > > fix in commit log and test description. > > > > I don't think dangerous is really necessary because this test won't run > on any kernels prior to those with the patch above, which is still > pending, and the crash issue had already been addressed in commit > cd87d8679 ("xfs: don't crash on unexpected holes in dir/attr btrees"). > > There is technically a crash possibility for custom kernels that > backport the later errortag patch without the earlier crash/corruption > fix, as you have for testing purposes. I think that is out of the > ordinary and doesn't really justify tagging the test, IMO. That makes sense, I'll drop dangerous group, thanks! Eryu -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
