copy_file_range test failures, maybe iscsi related?

[Dave Chinner <david@fromorbit.com>]

Hi folks,

I've just got my iscsi test systems back up and running and I'm
seeing tests generic/43[014] all getting stuck in the same way.
xfs_io is hard looping and not making progress, and the strace
output looks like this:

.....
copy_file_range(4, [1000], 3, [0], 100, 0) = 0
copy_file_range(4, [1000], 3, [0], 100, 0) = 0
copy_file_range(4, [1000], 3, [0], 100, 0) = 0
copy_file_range(4, [1000], 3, [0], 100, 0) = 0
copy_file_range(4, [1000], 3, [0], 100, 0) = 0
copy_file_range(4, [1000], 3, [0], 100, 0) = 0
copy_file_range(4, [1000], 3, [0], 100, 0) = 0
copy_file_range(4, [1000], 3, [0], 100, 0) = 0
copy_file_range(4, [1000], 3, [0], 100, 0) = 0
copy_file_range(4, [1000], 3, [0], 100, 0) = 0
copy_file_range(4, [1000], 3, [0], 100, 0) = 0
copy_file_range(4, [1000], 3, [0], 100, 0) = 0
copy_file_range(4, [1000], 3, [0], 100, 0) = 0
copy_file_range(4, [1000], 3, [0], 100, 0) = 0
.....

I can kill the xfs_io process and the test then fails and moves on
to the next, so it appears there's a problem with the
copy_file_range() implementation. On the same kernel (4.14-rc2) but
different devices (local SSD, ram disk or pmem) there is no problems
being reported by these tests and they complete extremely quickly.

It's clearly not related to XFS's reflink mkfs option, because I can
reproduce it on filesystems without that option enabled.  And I just
reproduced it on an ext4 filesystem, too, so this implies it is
probably an iscsi copy offload bug.

Is anyone else running xfstests on iscsi devices, and if so, are
they seeing these problems?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com