Zorro, I was analyzing a flakey test failure of xfs/517 and fell down a rabbit hole of frzon fs cleanups. Patch 4 fixes the false positive I was running into occasionnaly in cases where xfs/517 was completed successfully. While testing, I found out that if I interrupt the run of xfs/517 this often leaves the fs frozen. So I did an audit of the tests that freeze the fs and found that very few of them unfreeze fs on interrupt. This is an attempt to provide a robust solution that minimizes the risks of that happenning. I tested that all the tests in the 'freeze' group that I modified run to completion. I did not try to interrupt all the rest of the tests, because interrupting a test at exact time that it is frozen is quite hard. I did test that interrupting xfs/517 several times did not leave the fs frozen. Before the changes, it was rather easy to get it to leave a frozen fs behind, because the freeze_loop() keeps the fs frozon around half of the time that the test is running. As far as I can tell, this series is orthogonal to Dave's _cleanup() work [1]. It adds missing cleanups to tests (e.g. xfs/422) that could later make use of the common cleanup helpers (i.e. _fsstress_cleanup). However, the common _fsstress_cleanup() helper will need to kill without waiting. To my understand, Dave was also against waiting in the cleanup helper. Thanks, Amir. [1] https://lore.kernel.org/fstests/20220524073411.1943480-1-david@xxxxxxxxxxxxx/ Amir Goldstein (4): fstests: add missing _require_freeze() to tests fstests: make sure to unfreeze test and scratch mounts xfs/{422,517}: add missing killall to _cleanup() xfs/{422,517}: fix false positive failure check | 14 ++++++++------ common/rc | 5 +++-- tests/generic/390 | 2 -- tests/xfs/011 | 2 -- tests/xfs/119 | 1 + tests/xfs/318 | 3 ++- tests/xfs/325 | 3 ++- tests/xfs/422 | 16 ++++++++++++++-- tests/xfs/438 | 2 +- tests/xfs/517 | 8 ++++++-- 10 files changed, 37 insertions(+), 19 deletions(-) -- 2.25.1
