From: Petr Vorel <pvorel@suse.cz>
To: Murphy Zhou <jencce.kernel@gmail.com>
Cc: Yang Xu <xuyang2018.jy@cn.fujitsu.com>,
chrubis@suse.cz, ltp@lists.linux.it, linux-xfs@vger.kernel.org,
Clemens Famulla-Conrad <cfamullaconrad@suse.de>
Subject: Re: [LTP] [PATCH v7 3/3] syscalls/copy_file_range02: increase coverage and remove EXDEV test
Date: Tue, 27 Aug 2019 12:04:16 +0200 [thread overview]
Message-ID: <20190827100416.GB17923@dell5510> (raw)
In-Reply-To: <20190808035730.3kzors4trok6amtr@XZHOUW.usersys.redhat.com>
Hi Murphy,
> On Thu, Aug 08, 2019 at 11:11:43AM +0800, Yang Xu wrote:
> > on 2019/08/07 18:17, Murphy Zhou wrote:
> > > And I have a question about LTP itself.
> > > If we run the testcase directly like:
> > > ./testcases/kernel/syscalls/copy_file_range/copy_file_range02
> > > to test all_filesystems, for every filesystem, we mkfs and mount it in
> > > .mntpoint, but we do not chdir to .mntpoint. So we are running tests in
> > > the same tmpdir, fs type of which does not change while looping
> > > all_filesystems. Only the .mntpoint in tmpdir has different fs type in
> > > each loop.
> > > Now we are using this to test cross-device copy in copy_file_range01.c,
> > > but in copy_file_range02.c, we are not using .mntpint at all, all the
> > > tests in the all_filesystems loop are running in the same tmpdir. In other
> > > words, we are NOT testing all filesystems.
> > > Is this expected?
> > I removed the mnted test for cross-device copy_file_range in copy_file_range02.c.
> > And I ignore the non-used mntpoint. IMO, we can directly use the FILE_MNTED to test EFBIG on all filesystems,
> If mntpoint is not used, it makes absolutely NO sense to test all_filesystems.
Thanks for pointing this out. I was blind when reviewing this patchset.
At least this has been fixed.
> Because in the all_filesystems loop, various supported filesystems are
> created and mounted in mntpoint.
> And the copy_file_range tests happens outside of mntpoint. It just repeats
> the same test several times in the same tmpdir, fs type of which depends
> on /tmp configuration.
> When the log prints "testing ext2", it's not the truth.
> EFBIG is another issue.
Yep, we still need to think about different errnos, which depend on LTP policy
being defined [1].
> Thanks,
> Murphy
Kind regards,
Petr
[1] https://patchwork.ozlabs.org/patch/1143438/
prev parent reply other threads:[~2019-08-27 10:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190730110555.GB7528@rei.lan>
[not found] ` <1564569629-2358-1-git-send-email-xuyang2018.jy@cn.fujitsu.com>
[not found] ` <1564569629-2358-3-git-send-email-xuyang2018.jy@cn.fujitsu.com>
[not found] ` <20190805065832.ti6vpoviykfaxcj7@XZHOUW.usersys.redhat.com>
[not found] ` <5D47D6B9.9090306@cn.fujitsu.com>
[not found] ` <20190805102211.pvyufepn6xywi7vm@XZHOUW.usersys.redhat.com>
[not found] ` <20190806162703.GA1333@dell5510>
2019-08-07 10:17 ` [LTP] [PATCH v7 3/3] syscalls/copy_file_range02: increase coverage and remove EXDEV test Murphy Zhou
2019-08-07 12:12 ` Dave Chinner
2019-08-08 3:46 ` Murphy Zhou
2019-08-08 3:11 ` Yang Xu
2019-08-08 3:11 ` Yang Xu
2019-08-08 3:57 ` Murphy Zhou
2019-08-27 10:04 ` Petr Vorel [this message]
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=20190827100416.GB17923@dell5510 \
--to=pvorel@suse.cz \
--cc=cfamullaconrad@suse.de \
--cc=chrubis@suse.cz \
--cc=jencce.kernel@gmail.com \
--cc=linux-xfs@vger.kernel.org \
--cc=ltp@lists.linux.it \
--cc=xuyang2018.jy@cn.fujitsu.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox