[LTP] [PATCH v7 3/3] syscalls/copy_file_range02: increase coverage and remove EXDEV test

Murphy Zhou
2019-08-08T03:46:21Z

On Wed, Aug 07, 2019 at 10:12:12PM +1000, Dave Chinner wrote:
> On Wed, Aug 07, 2019 at 06:17:42PM +0800, Murphy Zhou wrote:
> > ccing linux-xfs@vger.kernel.org
> >
> > Hi,
> >
> > Tracked down this to be a xfs specific issue:
> >
> > If we call copy_file_range with a large offset like this:
> >
> > loff_t off = 9223372036854710270; // 2 ** 63
> > ret = copy_file_range(fd_in, 0, fd_out, &off, 65537, 0);
>
> That's not 2**63:

Ya! I was looking too roughly.

>
> $ echo $((9223372036854710270 + 65537))
> 9223372036854775807
>
> $ echo $((2**63 - 1))
> 9223372036854775807
>
> i.e. it's LLONG_MAX, not an overflow. XFS sets sb->s_maxbytes in
> xfs_max_file_offset to:
>
> (1 << BITS_PER_LONG - 1) - 1 = 2**63 - 1 = LLONG_MAX.
>
> So no matter how we look at it, this operation should not return
> EFBIG on XFS.
>
> > (test programme cfrbig.c attached)
> >
> > xfs has it done successfully, while ext4 returns EFBIG.
>
> ext4 has a max file size of 2**32 * blocksize, so it doesn't support
> files larger than 16TB. So it will give EFBIG on this test.
>
> /me compiles and runs the test program on his workstation:
>
> $ ls -l foobar
> -rw------- 1 dave dave 10737418240 Apr 12 14:46 foobar
> $ ./a.out foobar bar
> ret 65537
> $ ls -l bar
> -rw-r--r-- 1 dave dave 9223372036854775807 Aug 7 22:11 bar
> $
>
> That looks like a successful copy to me, not EINVAL or EFBIG...

Thanks Dave for the confirmation! This testcase needs some fix.

Murphy

>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com