Mateusz Guzik a7982d5d30 FreeBSD: fix up EXDEV handling for clone_range ... API contract requires VOPs to handle EXDEV internally, worst case by falling back to the generic copy routine. This broke with the recent changes. While here whack custom loop to lock 2 vnodes with vn_lock_pair, which provides the same functionality internally. write start/finish around it plays no role so got eliminated. One difference is that vn_lock_pair always takes an exclusive lock on both vnodes. I did not patch around it because current code takes an exclusive lock on the target vnode. zfs supports shared-locking for writes, so this serializes different calls to the routine as is, despite range locking inside. At the same time you may notice the source vnode can get some traffic if only shared-locked, thus once more this goes the safer route of exclusive-locking. Note this should be patched to use shared-locking for both once the feature is considered stable. Technically the switch to vn_lock_pair should be a separate change, but it would only introduce churn immediately whacked by the rest of the patch. Reviewed-by: Alexander Motin <mav@FreeBSD.org> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Mateusz Guzik <mjguzik@gmail.com> Sponsored by: Rubicon Communications, LLC ("Netgate") Closes #14723		2023-04-24 16:13:09 -07:00
..
freebsd	FreeBSD: fix up EXDEV handling for clone_range	2023-04-24 16:13:09 -07:00
linux	Linux: zfs_zaccess_trivial() should always call generic_permission()	2023-04-20 10:29:44 -07:00