Fix block cloning between unencrypted and encrypted datasets

[mmatuska]

Motivation and Context

When copying data from an unencrypted into an encrypted dataset and vice versa, block cloning should be not used. The current code checked only if the source was encrypted by reading the BP so when zfs_clone_range() was used to copy from unencrypted to encrypted the data remained unencrypted and caused a panic on read.

Fixes kernel panic in #15464

Description

Early check for zfs_clone_range() if we are copying from an unencrypted into an encrypted dataset or vice versa.

How Has This Been Tested?

Linux and FreeBSD

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.

[behlendorf]

cc: @pjd @robn

[robn]

Good find, and doing the check early is the best way.

We don't actually need anything from the block pointer to do the encryption checks, so the encrypted+same-filesystem check could also be lifted like this. But I wouldn't do that here; it all has to be revisited for encrypted cross-dataset anyway, and this is a nice narrow patch.

[oromenahar]

looks good to me. All the edge cases... thanks for the patch.
We will check again for enrypted datasets and if they are not the same. So we do not need to pay attention here.