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?
>
next prev parent 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 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.