Re: [RFC PATCH 2/2] swsusp: make it possible to hibernate to device mapper devices

[Milan Broz <gmazyland@gmail.com>]

On 12/18/25 12:18 AM, Askar Safin wrote:
> Mikulas Patocka <mpatocka@redhat.com>:
>> 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/3f3d871a-6a86-354f-f83d-a871793a4a47@redhat.com/ :
> 
>> 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?
>