[libcxx] copy_file enters an infinite loop in a multithreaded environment.

[Costatie]

When I use multiple threads to copy a file without locking, there are occasional instances where the copy_file operation seems to get stuck indefinitely.
By adding print logs before and after calling copy_file, it was discovered that the process was getting stuck during the call to copy_file_impl_copy_file_range.The main body of copy_file_impl_copy_file_range is a loop.

  do {
    ssize_t res;

    if ((res = ::copy_file_range(read_fd.fd, &off_in, write_fd.fd, &off_out, count, 0)) == -1) {
      ec = capture_errno();
      return false;
    }
    count -= res;
  } while (count > 0);

In the above scenario, the value of res was returned as 0. It appears that one of the two threads was continuously copying empty data.Why does this situation occur? Should we add a condition to check if res is 0 to prevent entering an infinite loop?

[Jannik2099]

Author of this function here. What's your src and dst filesystem? What's your kernel version?

In general, it's perfectly valid for copy_file_range to occasionally return 0

[ilyapopov]

@Jannik2099

man copy_file_range on Linux says:

If the file offset of fd_in is at or past the end of file, no bytes are copied, and copy_file_range() returns zero.

So if someone else has truncated the input file while it was being copied using copy_file_range, it will just repeatedly 0.

[bangbangziper-ship-it]

@Jannik2099 How about sendfile. I meet this question using copy_file_impl_sendfile。The src and dst filesystem is hmfs.

[Jannik2099]

Yeah, I can see the issue now, thanks.

Curiously, https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4100.pdf 15.4 fs.op.copy_file says

Complexity: At most one direct or indirect invocation of status(to).

So we are technically not allowed to fix it properly. And we can't assume that cfr / sendfile returning 0 means EOF either.

I guess we could lseek(SEEK_END) and check if the current offset is >= that