fuse copy_file_range() fixes

[kib]

Summary

fuse_vnop_copy_file_range(): add safety

v_mount for unlocked vnode could be NULL, check for it.  Explain why it
is safe to access fs-specific data for mp if it is read as non-NULL.

fuse_vnop_copy_file_range(): use vn_lock_pair()

[asomers]

LGTM. But under what circumstances can mp be NULL? We should probably add a regression test for that.

[kib]

In D42625#972575, @asomers wrote:

LGTM. But under what circumstances can mp be NULL? We should probably add a regression test for that.

The vnodes passed to VOP_COPY_FILE_RANGE() are not locked, so they can be reclaimed any moment. Then v_data and v_mount become NULL.

[kib]

vn_lock_pair() locks doomed vnodes; check for freed vnodes after the lock.

[jah]

sys/fs/fuse/fuse_vnops.c

883

Would VN_IS_DOOMED() be better here (since it would make the intention of the check clearer)?

[kib]

sys/fs/fuse/fuse_vnops.c

883

Then doomed but not yet reclaimed vnode cannot be handled. In principle there it is not very important, but other VOPs are more critical WRT this (subtle) difference. It is important for instance for fsync() or inactivate().

This is just my preference to be more permissive in such situations, after I realized this problem during some UFS work.