Fix decrypt_fault.ksh when zfs_abd_scatter_enabled=0

[tuxoko]

Motivation and Context

Description

If we turn off zfs_abd_scatter_enabled, we can allow buffer sharing
during arc_write_ready. However, this will cause decrypt_fault.ksh to
fail. It seems we need to export the pool to guarantee we will attempt
to decrypt the file again so fault injection will work.

How Has This Been Tested?

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.

[tuxoko]

For context, if we change arc_buf to take abd instead of normal buffer. We can allow buffer sharing even without turning off scatter abd. In which case this change is needed regardless of scatter abd being disabled or not.

[amotin]

Buffer sharing may happen for small blocks even with ABD scatter enabled. IIRC on Linux it means only up to 1KB, while on FreeBSD up to 4KB by default. Also it is allowed for UNCACHED headers, which are not supposed to live long.

[amotin]

I am not sure the old code is generally incorrect, even though it is not uniform in its behavior. If we are writing a block in plain-text (not via raw receive) and then encrypt as part of ZIO pipeline, we effectively have two versions of data: one plain-text in buf and one encrypted in zio->io_abd. So at this point we seem to be free to choose whether to put into ARC plain-text or encrypted data (or we may put even both, but it would be a waste of memory). If we put plain-text, then any consumer that later wants encrypted, will have to read it from disk, but consumers that want plain-text will get it as-is without decryption (this I suppose is what breaks the test, since there is just no decryption to fail). If we put encrypted data, then following plain-text read will have to decrypt it, wasting time, while encrypted read will get the data as-is. So the question seems to be what is more efficient (plain-text reads are probably much more likely) or is there any more artifacts hidden.

[tuxoko]

@amotin
Ok, then we make the test to purge the decrypted buffer instead?

[amotin]

While it is still a good question what shall we better do with this code, I think the test could instead be fixed by exporting/importing the pool instead of unmounting/mounting the dataset.

[tuxoko]

Update: revert the change and fix test instead.

[amotin]

I've never seen it before, but now for some reason it failed on (and only on) fedora41:

  21:48:32.00 SUCCESS: zinject -a -t data -e decrypt -f 20 /testpool/fs/file1
  21:48:32.11 SUCCESS: eval cat /testpool/fs/file1 > /dev/null exited 1
  21:48:32.32 ERROR: eval zpool events testpool | grep -q 'authentication' exited 1

[tuxoko]

Hmm... It seems more likely to fail when running multiple tests, but not single test.