From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yang Xu Date: Thu, 4 Jul 2019 18:35:04 +0800 Subject: [LTP] [PATCH] syscalls/copy_file_range02.c: Compatible with new and old kernels In-Reply-To: References: <1559292243-2882-1-git-send-email-huangjh.jy@cn.fujitsu.com> <5CF0FEB5.4030700@cn.fujitsu.com> <5D147856.5040709@cn.fujitsu.com> Message-ID: <5D1DD658.8050303@cn.fujitsu.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ltp@lists.linux.it on 2019/06/27 16:39, Amir Goldstein wrote: > On Thu, Jun 27, 2019 at 11:03 AM Yang Xu wrote: >> on 2019/05/31 21:02, Amir Goldstein wrote: >> >>> On Fri, May 31, 2019 at 3:03 PM Li Wang wrote: >>>> >>>> On Fri, May 31, 2019 at 6:15 PM Xiao Yang wrote: >>>>> On 2019/05/31 16:44, Jinhui huang wrote: >>>>>> On new kernels, copy_file_range() returned EISDIR when copyed contents >>>>>> to directory, but on old kernels, it returned EBADF, we should accept >>>>>> EBADF to be compatible with new and old kernels. >>>>>> >>>>>> The patch as follows: >>>>>> commit 11cbfb10775a ("vfs: deny copy_file_range() for non regular files") >>>>> Hi, >>>>> >>>>> From description of commit, I wonder if we can add more tests for some >>>>> non regular files(e.g. block, pipe)? >>>> I have no objection on this. But, is there really make sense to test some more non regular files which not being mentioned by Linux Manual Page? >>>> >>> FYI, more changes to copy_file_range checks are in the works: >>> https://lore.kernel.org/linux-fsdevel/20190526061100.21761-1-amir73il@gmail.com/T/#me34d4363449118bd3b2ec8421d282a77e9a7d2d1 >> Hi Amir >> >> Meet again. We can increase ltp copy_file_range02 coverage include( swapfile ->ETXTBUSY, immutable file->EPERM) as same as xfstests generic/553[4]. >> Also the two other checks(overlaping and offset wrap). I am glad to do it. > That would be great! Hi Amir I have tried it. swapfile and immutable file has no problem, but when I try to reproduce EINVAL(same file overlaping) without xfs_io, I got EFAULT error. It look likes we must depend on the new xfs_io feature patch. Right? ps: If it must xfs_io command, I think we can not check this situation because we should only check by copy_file_range syscall. what do you think about it? another question: I have seen copy_file_range manpage, it says fd_out data can be overwriting, but I got EFAULT when I use the following code. open(src_path, O_RDWR|O_CREAT, 0644) = fd_copy open(copy_path, O_RDWR|O_CREAT, 0644) = fd_src SAFE_WRITE(1, fd_src, CONTENT, CONTSIZE); SAFE_WRITE(1, fd_copy, CONTENT, CONTSIZE); copy_file_range(fd_src,0, fd_copy, CONTSIZE/4, CONTSIZE/2, 0) = -1 EFAULT fs/read_write.c copy_file_range function copy_from_user reports this error. If off_out or off_in isn't equal to 0, the error occurs. --------------------- ret= -EFAULT; .... if (off_out) { copy_from_user(&pos_out, off_out, sizeof(loff_t)); goto out; } ---------------------- Is it a bug or I miss something? Thanks Yang Xu > >> PS: Why we don't have test for overlaping and offset wrap check on xfstests? Or, I miss it? > The bounds check test was posted to xfstests: > https://marc.info/?l=linux-xfs&m=155947929219690&w=2 > > But because the test requires a new feature from xfs_io: > https://marc.info/?l=linux-xfs&m=156152984109774&w=2 > > I recommended that xfstests maintainer will hold off merging the test, > before the > required change is at least in xfsprogs for-next branch. > > Thanks, > Amir. > > >