Data-loss safety of "cryptsetup luksOpen <root device>" between suspend and resume

I'm setting up suspend-to-disk and resume in an 2021.12.x Arch Linux install. My question is about safely (without data-loss) unlocking partitions when resuming. Here is my configuration. The bootloader is grub 2.06, and I'm using a busybox-based initramfs. The relevant partitions are below. I'm not using LVM.

# partition	 encrypted	 mountpoint		decrypted volume name
- ---------  ---------   ----------     ---------------------
...
3 root		     luks2	 /				cryptroot
4 swap		     luks2	 [SWAP]			cryptswap
...

In /etc/mkinitcpio.conf I've configured these hooks.

HOOKS=(base udev ... openswap openroot ... resume ... filesystems fsck)

I'm not using the built-in encrypt hook. It can only unlock one device (typically only the root device which is specified in the cryptdevice kernel parameter), but I need to unlock the encrypted swap device, too. So instead of the encrypt hook I use two custom hooks: openswap and openroot. The openswap hook, in essence, runs: cryptsetup luksOpen cryptswap which prompts for a password. The openroot hook does the same for the root partition device: cryptsetup luksOpen cryptroot. Next, the built-in resume hook writes the swap device's major and minor numbers to /sys/power/resume .

printf "$devmajor:$devminor" >/sys/power/resume

There are two scenarios at this point. ### Scenario 1: If starting up after full shutdown When starting the computer after a full shutdown, there is no hibernation image in the unlocked swap partition. There is nothing to resume from, so a regular boot occurs. The root partition has been unlocked by this point (by the openroot hook), so booting can proceed correctly. No question of safety in this scenario. ### Scenario 2: If starting up after suspend-to-disk Earlier, when I would have initiated a suspend-to-disk, the root partition would have been in an unlocked and mounted state, and the hibernation image would have captured this state as is. Now, after kernel uses this hibernation image to resume, the system will continue to use this (already) unlocked/mounted root partition device. **This is where my question arises:** I know it is bad to *mount* a device in between suspend and resume. For example, kernel.org says : "If you touch anything on disk between suspend and resume… …kiss your data goodbye." My configuration doesn't do this. Is it similarly bad to cryptsetup luksOpen a device in between suspend and resume? Does cryptsetup luksOpen constitute touching (kernel.org terminology above) the disk? Recall that the initramfs openroot hook runs cryptsetup luksOpen cryptroot between suspend and resume. If so, how does one handle this?