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. > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
