Re: [PATCH 2/3] xfs: regression test for writes racing with reclaim writeback

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



On Wed, Dec 21, 2022 at 2:38 AM Darrick J. Wong <djwong@xxxxxxxxxx> wrote:
>
> From: Darrick J. Wong <djwong@xxxxxxxxxx>
>
> This test uses the new write delay debug knobs to set up a slow-moving
> write racing with writeback of an unwritten block at the end of the
> file range targetted by the slow write.  The test succeeds if the file
> does not end up corrupt and if the ftrace log captures a message about
> the revalidation occurring.
>
> NOTE: I'm not convinced that madvise actually causes the page to be
> removed from the pagecache, which means that this is effectively a
> functional test for the invalidation, not a corruption reproducer.
> On the other hand, the functional test can be done quickly.
>
> Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx>
> ---
>  tests/xfs/925     |  123 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  tests/xfs/925.out |    2 +
>  2 files changed, 125 insertions(+)
>  create mode 100755 tests/xfs/925
>  create mode 100644 tests/xfs/925.out
>
>
> diff --git a/tests/xfs/925 b/tests/xfs/925
> new file mode 100755
> index 0000000000..29490370bb
> --- /dev/null
> +++ b/tests/xfs/925
> @@ -0,0 +1,123 @@
> +#! /bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2022 Oracle.  All Rights Reserved.
> +#
> +# FS QA Test 925
> +#
> +# This is a regression test for a data corruption bug that existed in iomap's
> +# buffered write routines.
> +#

Please mention the kernel fix commit when writing a new test for
a bug fix.
Otherwise, it is hard for LTS xfs maintainers to figure out how to
test the backported fix.
For example, if LTS maintainers run this test on LTS kernel it won't
run because of the missing debug knob, so we need to make an
effort to make sure that there is test coverage if we decide to backport
the data corruption fix series.

My preference is using the _fixed_by_kernel_commit macro, because
it is always better to standardize information needed by tools.
If the printed $seqres.hints are a nuisance to some developers, I can easily
turn off printing of $seqres.hints by default and make that print opt-in, but
the collection of $seqres.hints files can only help analyse test failures on
LTS kernels.

Thanks,
Amir.



[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux