Re: Hard system lock-ups when using encrypted swap and RAM is exhausted

[Askar Safin <safinaskar@gmail.com>]

On Fri, Jan 2, 2026 at 4:47 PM Mikulas Patocka <mpatocka@redhat.com> wrote:
> Hi
>
> Dm integrity doesn't need to allocate memory when processing I/O requests

Thank you for answer!

Unfortunately, my experience shows the opposite thing.

[[ TL;DR: my experience shows that dm-integrity journaled mode is buggy, and
non-journaled mode is not. I. e. journaled mode seems to allocate memory, and
this causes temporary (for 4 minutes) lockups (on high specced
machine). Or maybe journaled mode has
some another bug, which causes such lockups. They are not reproducible in
non-journaled mode. ]]

2025-11-06  I started to use swap on dm-integrity on my main system in
journaled mode. My kernel
is Debian's 6.12.48 with some local patches. As always, I had a lot of
browser tabs opened, and
my virtual memory didn't fit into physical memory, i. e. the system
actively used swap.
Note that this is very high-specced machine.
Swap is on SSD. Swap size is 378 Gb. Memory size is 64 Gb.
This is Dell Precision 7780.
CPU is Intel Core i9. 32 cores.
Then somewhere around 2025-12-15 I opened even more browser tabs.
And soon the system started to misbehave. The system froze for 4
minutes in some moment.
Then the system thawed on its own and I saw in journalctl:

Dec 17 10:29:01 comp kernel: INFO: task pipewire:1303 blocked for more
than 120 seconds.
Dec 17 10:29:01 comp kernel:       Not tainted 6.12.48+deb13-amd64 #1
Debian 6.12.48-1
Dec 17 10:29:01 comp kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 17 10:29:01 comp kernel: task:pipewire        state:D stack:0
pid:1303  tgid:1303  ppid:1254   flags:0x00000002
Dec 17 10:29:01 comp kernel: Call Trace:
Dec 17 10:29:01 comp kernel:  <TASK>
Dec 17 10:29:01 comp kernel:  __schedule+0x505/0xc00
Dec 17 10:29:01 comp kernel:  schedule+0x27/0xf0
Dec 17 10:29:01 comp kernel:  io_schedule+0x46/0x70
Dec 17 10:29:01 comp kernel:  folio_wait_bit_common+0x132/0x320

(this repeats for multiple tasks.)

Here is "free -h" output:

|               total        used        free      shared  buff/cache
 available
|Mem:            62Gi        42Gi       2.6Gi       2.9Gi        20Gi
      19Gi
|Swap:          378Gi        87Gi       290Gi

I noticed similar freezes multiple times.

Then 2025-12-24 I changed dm-integrity mode from journaled to
non-journaled. And I rebooted.
(Note that I reboot very rarely. In other words, my system worked
without any reboot from 2025-11-06 to 2025-12-24 with zillions
of browser tabs opened. During this time I never rebooted, but
I sometimes suspended and hibernated.)

Okay, so, 2025-12-24 I changed dm-integrity mode. In fact,
I changed two things:

1) dm-integrity mode
2) I upgraded BIOS from 1.24.1 -> 1.26.0

Everything was the same. No software updated. Same kernel
binary with same patches.

And I didn't do any reboot since then. I. e. I didn't reboot from 2025-12-24
to 2026-01-10 . And during this time I never noticed long freezes. Sometimes
my system freezes for 1-3 seconds, but never more than that.

Note that my load is very big, similar to that Dec 17 freeze.

(And I'm totally sure culprit is dm-integrity mode change, not BIOS update.)

So, it seems that there is some bug in journaling mode.

But this bug is not important for me. I simply plan to use
non-journaling mode.

Moreover, even if you provide a fix, I likely will not test it,
because this would require me to use my system for
several days with high load. I simply don't want to do this.
I'm sorry about that.

But note that another bug I reported recently, namely
that "dm-integrity + hibernation" bug is important for me.
And I totally will test any patches if needed.

--
Askar Safin