On Tue, Mar 07, 2017 at 03:40:51PM -0800, Christoph Hellwig wrote: > On Fri, Mar 03, 2017 at 03:47:47PM -0500, J. Bruce Fields wrote: > > That's what I think too, but then is COPY(2) wrong?: > > Either the current kernel code or the man page is wrong.. > > > Also, copy_file_range can be implemented by ->clone_file_range, where > > these kinds of checks make more sense, I think; e.g. from btrfs: > > > > ret = -EINVAL; > > if (off + len > src->i_size || off + len < off) > > goto out_unlock; > > > > Well, so the caller just has to be prepared for either behavior, I > > guess, but that may make it more complicated to use. > > We'll need to stick to one behavior. So between the man page and > the clone implementation I guess this patch is fine after all. Ugh, please, let's not. Since copy isn't atomic that check is never going to be reliable. As long as we allow copy to have either copy-like or clone-like implementations, callers have to be prepared to handle either behavior when the range is past end of file, either a short copy or an EINVAL. The difference is that if we add this check, then the "short copy" behavior becomes something that only happens when the timing is just right. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
