On 12/18/25 12:18 AM, Askar Safin wrote:
Mikulas Patocka <[email protected]>:
Askar Safin requires swap and hibernation on the dm-integrity device mapper
target because he needs to protect his data.
Hi, Mikulas, Milan and others.
I'm running swap on dm-integrity for 40 days.
It runs mostly without problems.
But yesterday my screen freezed for 4 minutes. And then continued to work
normally.
So, may I ask again a question: is swap on dm-integrity supposed to work
at all? (I. e. swap partition on top of dm-integrity partition on top of
actual disk partition.) (I'm talking about swap here, not about hibernation.)
Hi,
I am not sure if Mikulas is available; maybe it's better to try again
in January...
Anyway, my understanding is that all device-mapper targets use mempools,
which should ensure that they can process even under memory pressure.
AFAIK, swap over a device-mapper target (any target!) with a real block device
should be ok. The problematic part is stacking over a filesystem (through a
loop)
as Mikulas mentioned.
If I interpret Mikulas' answer correctly, it is the filesystem that could
allocate memory here, and it deadlocks because of it (as it is swap itself).
So I believe it can happen with other DM targets too.
(If I am mistaken, please correct me.)
I wish it could work, but I do not understand kernel details anymore here.
It seems we are still in "a little walled gardens" communication issues
among various kernel subsystems, as one of the former maintainers said :-)
But you asked about a real block device, so it should work.
I guess it is just another bug you see...
Milan
Mikulas Patocka said here
https://lore.kernel.org/all/[email protected]/ :
Encrypted swap file is not supposed to work. It uses the loop device that
routes the requests to a filesystem and the filesystem needs to allocate
memory to process requests.
So, this is what happened to you - the machine runs out of memory, it
needs to swap out some pages, dm-crypt encrypts the pages and generates
write bios, the write bios are directed to the loop device, the loop
device directs them to the filesystem, the filesystem attempts to allocate
more memory => deadlock.
Does the same apply to dm-integrity?
I. e. is it possible that write to dm-integrity will lead to allocation?
