Re: [GIT PULL] fstests: updates on 2016-08-20

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Tue, Aug 23, 2016 at 03:16:08PM +0800, Eryu Guan wrote:
> On Tue, Aug 23, 2016 at 04:54:47PM +1000, Dave Chinner wrote:
> > On Sat, Aug 20, 2016 at 10:44:01PM +0800, Eryu Guan wrote:
> > > Hi Dave,
> > > 
> > > Can you please pull the fstests update from the location below? This is a
> > > normal update, which contains new generic and XFS tests and other fixes.
> > > 
> > > Thanks,
> > > Eryu
> > > 
> > > The following changes since commit c760a54061d26890be3929e4c6659bf3dc9e0c6a:
> > > 
> > >   src/t_immutable: allow EPERM on immutable inode (2016-08-12 11:17:34 +0800)
> > > 
> > > are available in the git repository at:
> > > 
> > >   https://github.com/guaneryu/xfstests.git for-dave
> > > 
> > > for you to fetch changes up to 3c75489a57518745598e239ffeec2af64400f185:
> > > 
> > >   common/rc: improve _require_metadata_journaling() for ext4 (2016-08-20 00:54:28 +0800)
> > > 
> > > ----------------------------------------------------------------
> > > 
> > > fstests: update on 2016-08-20
> > > 
> > > This update contains:
> > > o New tests for generic and XFS
> > > o Miscellaneous small fixes
> > > 
> > > ----------------------------------------------------------------
> > > Brian Foster (1):
> > >       generic: shutdown fs after log recovery
> > 
> > Hi Eryu,
> > 
> > I just pulled this all in and got an unexpected surprise - this new
> > test killed all of my test machines. From your description ("normal
> > update") I didn't expect to see something like this occur - I pulled
> > it, confirmed commits match, then pushed it to my test machines
> > and started a test cycle. I expected to see it complete without any
> > significant problems.
> 
> I saw only mount failures from this case in my testings (4.8-rc2
> kernel), I didn't expect any crash either.

Is this in reference generic/323?  For whatever reason I get a flood
of overlapping kernel stack smeared all over ttyS0.

--D

> 
> > 
> > The issue here is that this new test exercises a crash case and does
> > not have fixes that are upstream yet - we have review backlog that
> > has piled up while 4.8-rc1 regressions are being dealt with and
> > getting the xfsprogs rmap support reviewed and merged. Upstream can
> > only move as fast as review bandwidth will allow, and so sometimes
> > things don't get merged as quickly as we'd all like.
> 
> Understand.
> 
> > 
> > As such, can you try to hold off merging new tests that crash or
> > hang systems until the bug fixes have been committed in the upstream
> > repositories? This won't affect reviewers or testers (they grab
> > the test in themselves to exercise the problem), but for everyone
> > else merging it will just be a nuisance because there's nothing they
> > can do to make the test pass (excluding it is the only solution).
> 
> Sure, no problem. (ext4/022 has the same problem, it hangs kernel but
> the fixes are not in upstream yet, it has 'dangerous' group though.)
> 
> > 
> > In future, maybe it would be a good idea to ask the patch submitter
> > to tell you when the fix for a dangerous test like this has been
> > merged? That way you can and use that to determine when you push it
> > out for everyone? If it's just a pass/fail test it really doesn't
> > matter, but dangerous tests need to be handled a bit more
> > carefully.
> 
> That sounds good, I'll pay some attentions to the patch status too.
> 
> > 
> > For now, I'm going to hold off pushing this update out so other
> > people don't have to work around this issue whilst we clear out the
> > upstream patch backlog. Hopefully that won't take too long.
> 
> OKay. Thanks for all the information!
> 
> Thanks,
> Eryu
> --
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html