Among the motives for suspend-only swap spaces:
The proposed SWAP_FLAG_HIBERNATE_ONLY would reserve a swap space just for suspend-to-disk usage and not swapping regular pages. To now, generic swap ultimately needs to be enabled if just wanting to use it for system suspend, short of workarounds for turning it on/off around the suspend process.
There are a few reasons why usermode might want to be able to exclusively steer swap and hibernate. One reason relates to SSD wearing. Hibernate’s endurance and speed requirements are different from swap. It may for instance be advantageous to keep hibernate in primary storage, but put swap in an SLC namespace. These namespaces are faster and have better endurance, but cost 3-4x in terms of capacity. Exclusively steering hibernate and swap enables system designers to accurately partition their storage without either wearing out their primary storage, or overprovisioning their fast swap area.
Sent out today was the latest patch implementing this hibernate-only flag for swap. This revision changes the flag name and has various other code improvements for this proposed functionality.
Another reason to allow exclusive steering has to do with security. The requirements for designing systems with resilience against offline attacks are different between swap and hibernate. Swap effectively requires a dictionary of hashes, as pages can be added and removed arbitrarily, whereas hibernate only needs a single hash for the entire image. If you’ve set up block-level integrity for swap and image-level integrity for hibernate, then allowing swap blocks to possibly leak out to the hibernate region is problematic, since it creates swap pages not protected by any integrity.