public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] lapi/fs.h: Replace MAX_LFS_FILESIZE constant with own implementation
Date: Tue, 20 Aug 2019 17:09:48 +0800	[thread overview]
Message-ID: <5D5BB8DC.6070900@cn.fujitsu.com> (raw)
In-Reply-To: <CAEemH2d7TYn4sZ7kkjRsPc-yBnTrN9LC+w84MAO6pDxYpfiFcw@mail.gmail.com>

on 2019/08/19 16:16, Li Wang wrote:

> On Fri, Aug 16, 2019 at 4:53 PM Murphy Zhou<jencce.kernel@gmail.com>  wrote:
>> On Thu, Aug 15, 2019 at 10:36:30AM +0200, Petr Vorel wrote:
>>> Some libc implementations on arm (at least AArch32 target with hard
>>> float (arm-linux-gnueabihf)) or some libc (musl, bionic) does not
>>> export PAGE_SHIFT. Replace it with own inline function.
>>>
>>> This required to replace MAX_LFS_FILESIZE constant with function
>>> tst_max_lfs_filesize(). Given that we must use MAX_OFF in a function,
>>> move dst from tcase struct to verify_copy_file_range().
>>>
>>> Credits for 32 bit MAX_LFS_FILESIZE algorithm: Cyril Hrubis.
>> I got the same results:
>>
>> copy_file_range02.c:120: INFO: dst 9223372036854710270 len 65537
>> copy_file_range02.c:136: FAIL: copy_file_range returned wrong value: 32
> I'm not chanllenge the tst_max_lfs_filesize().
>
> But I don't understand why to define MAX_OFF as (MAX_LEN - MIN_OFF),
> the failure indicates that not to write at a position past the maximum
> allowed offset. Shouldn't we give a dst_off large than
> MAX_LFS_FILESIZE?
Yes, we should use a dst_off large than MAX_LFS_FILESIZE because it used pos to compare
in kernel code as below:

mm/filemap.c
  static int generic_write_check_limits(struct file *file, loff_t pos, loff_t *count)
...
if (unlikely(pos>= max_size))
   return -EFBIG;
...

I strace xfstest generic/564 code( I follow this test code to ltp), as below:
#max_off=$((8 * 2**60 - 65536 - 1))
#min_off=65537
#xfs_io -f -c "pwrite -S 0x61 0 128k" file
#touch copy
#strace xfs_io -c "copy_range -l $min_off -s 0 -d $max_off file" copy
....
  openat(AT_FDCWD, "file", O_RDONLY)      = 4
  copy_file_range(4, [0], 3, [9223372036854710271], 65537, 0) = 65536
  copy_file_range(4, [65536], 3, [9223372036854775807], 1, 0) = -1 EFBIG (File too large)
....

xfsprogs used a loop to call copy_file_range, and get EFBIG when pos greater than LLONG_MAX.

I think we should  use tst_max_lfs_filesize instead of (tst_max_lfs_filesize -MIN_OFF)
and this case will pass whether xfs,btrfs and ext4.

Thanks for pointing out this.

> if I change the code as below, then it could be passed.
>
> --- a/testcases/kernel/syscalls/copy_file_range/copy_file_range02.c
> +++ b/testcases/kernel/syscalls/copy_file_range/copy_file_range02.c
> @@ -115,7 +115,7 @@ static void verify_copy_file_range(unsigned int n)
>          }
>
>          if (tc->copy_to_fd ==&fd_copy)
> -               dst = tst_max_lfs_filesize() - MIN_OFF;
> +               dst = tst_max_lfs_filesize();
>
>




  reply	other threads:[~2019-08-20  9:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-15  8:36 [LTP] [PATCH] lapi/fs.h: Replace MAX_LFS_FILESIZE constant with own implementation Petr Vorel
2019-08-16  8:53 ` Murphy Zhou
2019-08-19  8:16   ` Li Wang
2019-08-20  9:09     ` Yang Xu [this message]
2019-08-21  7:27       ` Li Wang
2019-08-21  8:14         ` Yang Xu
2019-08-23  3:10           ` Murphy Zhou
2019-08-23  7:23 ` Li Wang
2019-08-26  8:50   ` Petr Vorel

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=5D5BB8DC.6070900@cn.fujitsu.com \
    --to=xuyang2018.jy@cn.fujitsu.com \
    --cc=ltp@lists.linux.it \
    /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