FreeBSD: fix up EXDEV handling for clone_range
commita7982d5d30dabd2e206011f54226b25d6c70c4d6
authorMateusz Guzik <mjguzik@gmail.com>
Wed, 5 Apr 2023 21:12:17 +0000 (5 21:12 +0000)
committerBrian Behlendorf <behlendorf1@llnl.gov>
Mon, 24 Apr 2023 23:13:09 +0000 (24 16:13 -0700)
tree336005548fb777ec28a06005f717e8308c3a7b7b
parent62cc9d4f6b5ad3a16b97f6389828b20331863f40
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
module/os/freebsd/zfs/zfs_vnops_os.c