All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: fstests@vger.kernel.org
Subject: [PATCH 0/3] fstests: copy_file_range() bounds testing
Date: Mon,  3 Dec 2018 17:42:53 +1100	[thread overview]
Message-ID: <20181203064256.26768-1-david@fromorbit.com> (raw)

Hi folks,

We suck at bounds testing new system calls. This is a test that
exercises the expected failure cases for copy_file_range(). It's
going to fail miserably on existing kernels - I'm about to post a
series of fixes to linux-fsdevel that make this test pass.

The test is also dependent on xfs_io changes that I posted a few
hours ago. The three (not 2!) patches can be found here:

https://marc.info/?l=linux-xfs&m=154378403323889&w=2
https://marc.info/?l=linux-xfs&m=154378403523890&w=2
https://marc.info/?l=linux-xfs&m=154378403323888&w=2
https://marc.info/?l=linux-xfs&m=154379644526132&w=2

Comments welcome.

-Dave

---

As an aside, one thing that I've discovered in writing this test is
that certain things we do to test certain file conditions are not
being tested corectly. e.g. immutable files.

When we set a file as immutable and then go to modify it with xfs_io
like this:

# xfs_io -c "chattr +i" test_file
# xfs_io -c "pwrite 0 4k" test_file

We are not actually testing whether the pwrite() syscall detected
that it can't write to an immutable file. xfs_io actually fails when
the open(O_RDWR) syscall fails because we can't open an immutable
file for writing. IOWs, it's not testing pwrite() at all.

Hence tests like generic/159 and generic/160 are not actually
testing whether cloning/deduping files fails on immutable files.

Instead, what we need to do is open the file O_RDWR, then set the
file immutable, then perform the modification operation. i.e. this:

# xfs_io -c "chattr +i" -c "pwrite 0 4k" test_file

Will exercise the pwrite() syscall hitting an immutable file. A
similar thing happens with trying to write/modify to read only files
- the open() call fails, not the call that we want to test. That's
why I added the "chmod" operation to xfs_io, to allow us to open a
file for write, then turn it read only while we still have a
writeable fd open. This then exercises trying to write/modify a
read-only file.

I'm sure there's lots of tests that have these problems. I don't
have time to audit them right now, but I'm bringing it up so that
people are aware of the issue and at least catch problems like this
in new tests....

             reply	other threads:[~2018-12-03  6:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-03  6:42 Dave Chinner [this message]
2018-12-03  6:42 ` [PATCH 1/3] common: add _require_test_swapfile Dave Chinner
2018-12-03 16:43   ` Darrick J. Wong
2018-12-13 12:16   ` Xiao Yang
2018-12-18 21:54     ` Dave Chinner
2018-12-03  6:42 ` [PATCH 2/3] generic/43[014]: copy_range beyond source EOF should fail Dave Chinner
2018-12-03  7:30   ` Amir Goldstein
2018-12-03  8:10     ` Dave Chinner
2018-12-03 16:47   ` Darrick J. Wong
2018-12-05 22:23   ` Dave Chinner
2018-12-03  6:42 ` [PATCH 3/3] generic: copy_file_range bounds test Dave Chinner
2018-12-03  7:25   ` Amir Goldstein
2018-12-03  8:17     ` Dave Chinner
2018-12-03  9:22       ` Amir Goldstein
2018-12-03 13:15         ` Amir Goldstein
2019-05-13  6:03         ` Amir Goldstein
2018-12-03 16:58   ` Darrick J. Wong
2019-05-21  5:33   ` Amir Goldstein
2018-12-03 16:41 ` [PATCH 0/3] fstests: copy_file_range() bounds testing Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181203064256.26768-1-david@fromorbit.com \
    --to=david@fromorbit.com \
    --cc=fstests@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.