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