On Sun, May 22, 2022 at 5:10 PM Zorro Lang <zlang@xxxxxxxxxx> wrote: > > On Fri, May 20, 2022 at 05:32:49PM +0300, Amir Goldstein wrote: > > In preparation for backporting xfs fixes to stable kernel 5.10.y, > > annotate some of the tests that pass after applying the backports. > > > > Most of the annotated tests have the fix commit documented either > > in comment or in commit message already. > > > > All tests have been verified to pass with fix commits apply, but > > for a few tests, a failure was observed when running on kernel without > > the documented fix commit. That is probably because failure happens > > only on a specific setup. > > > > Generic tests have also been annotated with xfs fix commits. > > That may produce wrong hints if the test fails on another fs, but > > that is what hints are for - to give tester a hint, so if tester is > > not testing xfs, it's easy to figure out that the hint is irrelevant. > > > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > > --- > > > > Hi Zorro, > > > > Here are a bunch of fixed_by annotations for xfs bug fixes, > > which I am in the process of testing for stable kernel v5.10.y [1]. > > I just confirmed that these commit IDs are right, and these cases are > specific reproducer for them. So I'd like to ack this patch. > > Reviewed-by: Zorro Lang <zlang@xxxxxxxxxx> > > > > > There are a lot more tests with fix commits documented in comments > > and/or commit message, but I did not annotate any test that I did not > > verify myself to pass with the fix commit. > > Thanks for you did that such carefully. You remind me that I just release > a new fstests version v2022.05.22, which has several known failures too. > https://lore.kernel.org/fstests/20220522094622.25751C385AA@xxxxxxxxxxxxxxx/T/#u > > I'm thinking about another question, if a case covers more and more known > issue, the known list will be very long, even might take 1/3 of the code > lines. That will look not graceful ... > > We'd better to not make an existed case grow biger and biger. And don't > record known issues in a case which just can reproduce it with small chance No of course not, that would not be productive. fixed_by_commit should be reserved to "proper" regression tests failing before fix, passing after fix There could still be several fixed_by commits for different fs and for different regressions that were detected on different kernel versions. > randomly. Likes you record e4826691cc7e ("xfs: restore shutdown check in mapped > write fault path") into g/623, actually we found it by g/019 at first, then > write g/623 to cover that. So g/019 isn't the recommended case to record this > issue. > Exactly. Good example. Thanks, Amir.
