From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A1E9D3851C17; Wed, 5 Aug 2020 14:01:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A1E9D3851C17 From: "adhemerval.zanella at linaro dot org" To: glibc-bugs@sourceware.org Subject: [Bug build/26338] io/tst-copy_file_range fails on RHEL 7.8 hosts Date: Wed, 05 Aug 2020 14:01:11 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: build X-Bugzilla-Version: 2.33 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: adhemerval.zanella at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 14:01:11 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26338 --- Comment #4 from Adhemerval Zanella --- (In reply to Florian Weimer from comment #3) > I assume the upstream kernel would behave in the same way (succeed with > length 0, fail with any other length) if a file system does something so > that the generic splice-based copy_file_range fails, so maybe this is a t= est > bug after all. Skimming through kernel sources it seems that is EOPNOTSUPP is usually the preferred code instead: fs/fuse/file.c 3275 static ssize_t __fuse_copy_file_range(struct file *file_in, loff_t pos= _in, 3276 struct file *file_out, loff_t pos_out, 3277 size_t len, unsigned int flags) [...] 3302 if (fc->no_copy_file_range) 3303 return -EOPNOTSUPP; fs/cifs/cifsfs.c 1207 static ssize_t cifs_copy_file_range(struct file *src_file, loff_t off, 1208 struct file *dst_file, loff_t destoff, 1209 size_t len, unsigned int flags) 1210 { 1211 unsigned int xid =3D get_xid(); 1212 ssize_t rc; 1213 struct cifsFileInfo *cfile =3D dst_file->private_data; 1214=20 1215 if (cfile->swapfile) 1216 return -EOPNOTSUPP; 1217=20 1218 rc =3D cifs_file_copychunk_range(xid, src_file, off, dst_file, destoff, 1219 len, flags); 1220 free_xid(xid); 1221=20 1222 if (rc =3D=3D -EOPNOTSUPP || rc =3D=3D -EXDEV) 1223 rc =3D generic_copy_file_range(src_file, off, dst_file, 1224 destoff, len, flags); 1225 return rc; 1226 } fs/fuse/file.c 3275 static ssize_t __fuse_copy_file_range(struct file *file_in, loff_t pos= _in, 3276 struct file *file_out, loff_t pos_out, 3277 size_t len, unsigned int flags) 3278 { [...] 3302 if (fc->no_copy_file_range) 3303 return -EOPNOTSUPP; fs/nfs/nfs4file.c 132 static ssize_t __nfs4_copy_file_range(struct file *file_in, loff_t pos_= in, 133 struct file *file_out, loff_t pos_out, 134 size_t count, unsigned int flags) 135 { [...] 145 if (!nfs_server_capable(file_inode(file_out), NFS_CAP_COPY)) 146 return -EOPNOTSUPP; 147 if (file_inode(file_in) =3D=3D file_inode(file_out)) 148 return -EOPNOTSUPP; [..] 161 if (sync || 162 count <=3D 14 * NFS_SERVER(file_inode(file_in))->rsize) 163 return -EOPNOTSUPP; So I don't think ENOSYS as RHEL 7.8 is doing is the correct way to advertise the syscall does not work depending of the underlying filesystem (at least = it seems not what upstream is doing). --=20 You are receiving this mail because: You are on the CC list for the bug.=