Fix 2 bugs in non-raw send with encryption

Bisecting identified the redacted send/receive as the source of the bug
for issue #12014. Specifically the call to
dsl_dataset_hold_obj(..&fromds) had been replaced by
dsl_dataset_hold_obj_flags() which would pass a DECRYPT flag and create
a key mapping. The problem here arises when trying to access the
MASTER_NODE_OBJ that key mapping is used and the code panics. Fix this
by restoring the call to dsl_dataset_hold_obj().

Later on in dmu_send_obj() the change dsl_dataset_rele(on to_ds) to
dsl_dataset_rele_flags(), otherwise the created key mapping (on to_ds)
earlier on is leaked, which result in panicking when exporting the
sending pool or unloading the zfs module after a non-encrypted send from
an encrypted filesystem.

Signed-off-by: George Amanakis <[email protected]>

Author: gamanakis

module/zfs/dmu_send.c

@@ -2688,8 +2688,8 @@ dmu_send_obj(const char *pool, uint64_t tosnap, uint64_t fromsnap,
 	}
 
 	if (fromsnap != 0) {
-		err = dsl_dataset_hold_obj_flags(dspp.dp, fromsnap, dsflags,
-		    FTAG, &fromds);
+		err = dsl_dataset_hold_obj(dspp.dp, fromsnap, FTAG, &fromds);
+
 		if (err != 0) {
 			dsl_dataset_rele_flags(dspp.to_ds, dsflags, FTAG);
 			dsl_pool_rele(dspp.dp, FTAG);
@@ -2741,7 +2741,7 @@ dmu_send_obj(const char *pool, uint64_t tosnap, uint64_t fromsnap,
 		kmem_free(dspp.fromredactsnaps,
 		    dspp.numfromredactsnaps * sizeof (uint64_t));
 
-	dsl_dataset_rele(dspp.to_ds, FTAG);
+	dsl_dataset_rele_flags(dspp.to_ds, dsflags, FTAG);
 	return (err);
 }