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: Wed, 21 Aug 2019 16:14:45 +0800	[thread overview]
Message-ID: <5D5CFD75.3050506@cn.fujitsu.com> (raw)
In-Reply-To: <CAEemH2d_CKOwE3mHEXZKi1BkMBw5dn95aMJtkrSRciH2PU6NJA@mail.gmail.com>

on 2019/08/21 15:27, Li Wang wrote:

> On Tue, Aug 20, 2019 at 5:10 PM Yang Xu<xuyang2018.jy@cn.fujitsu.com>  wrote:
> ...
>>> 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.
> Good job, Xu. I think you can format a new patch to fix this problem.
> Because Petr's patch is used for solving the cross-compiling issue and
> looks good.
Hi Li

OK. I will send a new patch to fix this problem. But copy_file_range02.c still has a problem as Murphy found,
we set all_filesystem but use the same tmpdir instead of mntpoint.  I think we can remove all_filesystem and mountpoint.

@Murphy Zhou  Hi Murphy, would you like to send a new patch to remove useless all_filesystem or I do it in my
new patch by adding your signed-off-by tag? What do you think about it?

> @Petr Vorel Hi Petr, what do you think? any more comments?
>




  reply	other threads:[~2019-08-21  8:14 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
2019-08-21  7:27       ` Li Wang
2019-08-21  8:14         ` Yang Xu [this message]
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=5D5CFD75.3050506@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