FreeBSD: Reduce copy_file_range() source lock to shared

[amotin]

Linux locks copy_file_range() source as shared. FreeBSD was doing it also, but then was changed to exclusive, partially because KPI of that time was doing so, and partially seems out of caution. Considering zfs_clone_range() uses range locks on both source and destination, neither should require exclusive vnode locks. But one step at a time, just sync it with Linux for now.

Closes #16789

How Has This Been Tested?

Passes fsx test from #16789, even though #16796 should be the proper fix.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[asomers]

This looks good to me. It's what same lock type that fuse_vnop_copy_file_range, vn_generic_copy_file_range, and nfs_copy_file_range use. But was it your intention that either this PR or #16796 alone should fix the panic? Because I can still reproduce the panic with this change but without #16796.

[amotin]

But was it your intention that either this PR or #16796 alone should fix the panic?

No, not really. I thought that shared lock recursion should be less of a problem, and IIRC it passed some tests for me, but I don't insist on it.