copy_file_range() returns EAGAIN for direct=always but succeeds for direct=standard on non-recordsize-aligned requests

[ixhamza]

System information

Type	Version/Name
Distribution Name	Ubuntu 24.04.1 LTS
Distribution Version	24.04
Kernel Version	6.8.0-51-generic
Architecture	x86_64
OpenZFS Version	zfs-2.3.0-1

Describe the problem you're observing

When a block clone fallback is performed with direct=always, the function zfs_setup_direct() (called by zfs_read()) appears to fail with EFAULT during the execution of zfs_uio_get_dio_pages_alloc() -> zfs_uio_pin_user_pages() -> pin_user_pages_unlocked(), although the kernel converts EFAULT to EAGAIN later.
Note: Same test results in panic when executed in older kernel version, i.e., #16952.

Describe how to reproduce the problem

Fails with direct=always

truncate -s 1G /tmp/f1
sudo zpool create tank /tmp/f1 -O direct=always
sudo dd if=/dev/urandom of=/tank/file bs=128K count=4
sudo zpool sync tank
sudo ./tests/zfs-tests/bin/clonefile -f /tank/file /tank/clone 0 262144 196608
using copy_file_range
copy_file_range: Resource temporarily unavailable
file offsets: src=0/524288; dst=0/0

Passes with direct=standard

truncate -s 1G /tmp/f1
sudo zpool create tank /tmp/f1 -O direct=standard
sudo dd if=/dev/urandom of=/tank/file bs=128K count=4
sudo zpool sync tank
sudo ./tests/zfs-tests/bin/clonefile -f /tank/file /tank/clone 0 262144 196608
using copy_file_range
file offsets: src=0/524288; dst=0/458752

Include any warning/errors/backtraces from the system logs

clonefile reports: "copy_file_range: Resource temporarily unavailable when request offset or size is not aligned to recordsize"