Re: [PATCH v3] generic: add a test to ensure that page is properly filled before write

[Jeff Layton <jlayton@kernel.org>]

On Mon, 2021-07-05 at 19:04 +0800, Zorro Lang wrote:
> On Fri, Jul 02, 2021 at 09:40:24AM -0400, Jeff Layton wrote:
> > We had a broken optimization in cephfs and netfs lib that could cause
> > part of a page to be improperly zeroed-out when writing to an offset
> > that was beyond the EOF but in an existing page.
> > 
> > Add a simple test that would have caught this.
> > 
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> >  tests/generic/639     | 39 +++++++++++++++++++++++++++++++++++++++
> >  tests/generic/639.out |  5 +++++
> >  2 files changed, 44 insertions(+)
> >  create mode 100755 tests/generic/639
> >  create mode 100644 tests/generic/639.out
> > 
> > v3: adapt to new test template
> > 
> > diff --git a/tests/generic/639 b/tests/generic/639
> > new file mode 100755
> > index 000000000000..c30f7644a2fc
> > --- /dev/null
> > +++ b/tests/generic/639
> > @@ -0,0 +1,39 @@
> > +#! /bin/bash
> > +# SPDX-License-Identifier: GPL-2.0
> > +# Copyright (c) 2021, Jeff Layton <jlayton@redhat.com>
> > +#
> > +# FS QA Test No. 639
> > +#
> > +# Open a file and write a little data to it. Unmount (to clean out the cache)
> > +# and then mount again. Then write some data to it beyond the EOF and ensure
> > +# the result is correct.
> > +#
> > +# Prompted by a bug in ceph_write_begin that was fixed by commit 827a746f405d.
> > +#
> > +. ./common/preamble
> > +_begin_fstest auto quick rw
> > +
> > +# Import common functions.
> > +. ./common/filter
> > +
> > +# real QA test starts here
> > +_supported_fs generic
> > +_require_test
> > +
> > +testfile="$TEST_DIR/test_write_begin.$$"
> > +
> > +# write some data to file and fsync it out
> > +$XFS_IO_PROG -f -c "pwrite -q 0 32" $testfile
> 
> Looks good to me, if you've used this case to reproduce that issue.
> 
> Just one question, the comment says "fsync it out", does that mean we need an
> explicit "fsync" call (e.g. -c "pwrite -q 0 32" -c "fsync") to reproduce this
> bug? Or there's an implicit "fsync" somewhere?
> 
> 

No, there is no implicit fsync. This is holdover from copy/paste that I
did from another test. The patch is already merged now, but if we expand
this test to cover other cases, I'll plan to clean up the comment then.

Thanks,
Jeff

> 
> > +
> > +# cycle the mount to clean out the pagecache
> > +_test_cycle_mount
> > +
> > +# now, write to the file (near the end)
> > +$XFS_IO_PROG -c "pwrite -q 32 32" $testfile
> > +
> > +# dump what we think is in there
> > +echo "The result should be 64 bytes filled with 0xcd:"
> > +hexdump -C $testfile
> > +
> > +status=0
> > +exit
> > diff --git a/tests/generic/639.out b/tests/generic/639.out
> > new file mode 100644
> > index 000000000000..9bf0bac96864
> > --- /dev/null
> > +++ b/tests/generic/639.out
> > @@ -0,0 +1,5 @@
> > +QA output created by 639
> > +The result should be 64 bytes filled with 0xcd:
> > +00000000  cd cd cd cd cd cd cd cd  cd cd cd cd cd cd cd cd  |................|
> > +*
> > +00000040
> > -- 
> > 2.31.1
> > 
> 

-- 
Jeff Layton <jlayton@kernel.org>