Message-ID: <20251127173702.6c8a7ba2@kf-m2g5>
Date: Thu, 27 Nov 2025 17:37:02 -0600
From: Aaron Rainbolt <arraybolt3@...il.com>
To: Milan Broz <gmazyland@...il.com>
Cc: linux-mm@...ck.org, cryptsetup@...ts.linux.dev,
 "dm-devel@...ts.linux.dev" <dm-devel@...ts.linux.dev>,
 linux-kernel@...r.kernel.org, adrelanos@...nix.org, Mikulas Patocka
 <mpatocka@...hat.com>
Subject: Re: Hard system lock-ups when using encrypted swap and RAM is
 exhausted

On Thu, 27 Nov 2025 08:59:13 +0100
Milan Broz <gmazyland@...il.com> wrote:

> Hi,
> 
> On 11/12/25 6:18 AM, Aaron Rainbolt wrote:
> > Not sure if this is a memory management issue, a LUKS issue, or
> > both, so I wrote both mailing lists.  
> 
> It is not a LUKS issue; cryptsetup/LUKS activates the encrypted
> device, so it is only the kernel/dm-crypt handling IOs.
> 
> Adding cc to dm-devel as this would be another combination
> device-mapper and encrypted swap that could cause issues...
> 
> However, could you please specify exactly your storage configuration?
> 
>  From the subject, I expected you to have an encrypted swap, but it is
> not clear if there are other encrypted devices.
>
> Please paste at least lsblk, lsblk -f output, and also luksDump
> (or crypttab if it is not LUKS) for LUKS/dm-crypt configuration.

Mikulas seems to have reproduced the issue already, but just in case
it's still useful, here's the requested data, along with /etc/fstab.
(/dev/sda2 is a BIOS boot partition.)

-----

[sysmaint ~]% lsblk    
NAME   MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
loop0    7:0    0    4G  0 loop  
└─swap 254:0    0    4G  0 crypt [SWAP]
sda      8:0    0  100G  0 disk  
├─sda1   8:1    0  100M  0 part  /boot/efi
├─sda2   8:2    0    1M  0 part  
└─sda3   8:3    0 99.9G  0 part  /

-----

[sysmaint ~]% lsblk -f
NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0  swap   1           0a06fb5a-39f5-4a89-b8a8-fdc2470ee0f3    
└─swap swap   1     swap  f9aa44bb-2214-4a32-ac7e-34360b0f313b                [SWAP]
sda    
├─sda1 vfat   FAT32 EFI   6907-5000                                           /boot/efi
├─sda2    
└─sda3 ext4   1.0         26ada0c0-1165-4098-884d-aafd2220c2c6   64.7G    29% /

-----

[sysmaint ~]% cat /etc/crypttab    
# <target name> <source device>         <key file>      <options>
swap /swapfile /dev/urandom swap,noearly

-----

[sysmaint ~]% cat /etc/fstab    
# /etc/fstab - created by grml-debootstrap on Sun Nov  2 20:23:37 UTC 2025
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
/dev/disk/by-uuid/26ada0c0-1165-4098-884d-aafd2220c2c6 /  auto    defaults,errors=remount-ro,x-systemd.growfs 0   1   
UUID=6907-5000  /boot/efi       vfat    umask=0077      0       1   
proc           /proc        proc    defaults                      0   0   
/dev/cdrom     /mnt/cdrom0  iso9660 ro,user,noauto                0   0   
# some other examples:
# /dev/sda2       none         swap    sw,pri=0             0   0   
# /dev/hda1       /Grml        ext3    dev,suid,user,noauto 0  2
# //1.2.3.4/pub   /smb/pub     cifs    user,noauto,uid=grml,gid=grml 0 0 
# linux:/pub      /beer        nfs     defaults             0  0
# tmpfs           /tmp         tmpfs   size=300M            0  0
# /dev/sda5       none         swap    sw                   0  0
/dev/mapper/swap none swap sw 0 0

--
Aaron

> Thanks,
> Milan
> 
> 
> > 
> > I'm seeing an issue with both the latest mainline kernel (6.18-rc5)
> > and Debian 13's 6.12 kernel package. When physical memory fills up,
> > the entire system locks up hard, as if it hit rather severe
> > thrashing, despite the fact that there appears to be disk cache
> > that can still be evicted, and there is ample amounts of swap space
> > remaining (gigabytes of it). This issue did not occur with the 6.1
> > kernel in Debian 12. I'm seeing this occur in very low-memory
> > Debian VMs, with between 512 and 900 MB RAM, running under
> > VirtualBox and KVM. (I suspect, but have not verified, that I'm
> > seeing similar behavior under Xen as well.) These VMs generally use
> > a swappiness of 1, though I have seen a lockup occur even with a
> > swappiness of 60. The filesystem in use, in case it matters, is
> > ext4.
> > 
> > To reproduce on a system running Linux 6.18-rc5, with :
> > 
> > * Follow the steps from
> >    https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions,
> >    section "2.3 How do I set up encrypted swap?", but creating a
> >    swapfile rather than a swap partition. I created an 8 GB swapfile
> >    with fallocate. Reboot the system when done.
> > * In a TTY, open a terminal multiplexer (or something you can abuse
> > as one, Vim works well), and open two terminals. In one terminal,
> > run `htop` so you can observe memory and swap usage.
> > * In the `htop` terminal, sort by M_RESIDENT.
> > * In the other terminal, create a new file `test.py`, that will
> >    gradually fill memory at a relatively fast pace and print an
> >    indicator that it's still alive. I used the following code for
> > this:
> > 
> >      import time
> > 
> >      count = 0
> >      mem_list = []
> >      while True:
> >          mem_list.append([x for x in range(2048)])
> >          count += 1
> >          time.sleep(0.002)
> >          print(count)
> > 
> > * Run the script with `python3 test.py`.
> > * While the script runs, observe the growing memory usage in `htop`.
> >    Swap usage should start at or near 0, RAM usage will gradually
> >    increase. Once RAM usage starts getting high, some data will
> > start being swapped out as expected, but after a short while the
> > whole VM will lock up despite there being gigabytes of swap left.
> > (On my KVM VM, the last time htop updated its screen, it showed RAM
> > usage of 712M/846M, and swap usage of 328M/7.40G. The python3
> > process running the script was consuming 551M memory. The VM is
> > entirely unresponsive. Incidentally, the python3 process also was in
> >    uninterruptible sleep when htop last updated its screen, but that
> >    could mean nothing since it might have come out of sleep between
> > the last screen update and the VM lockup.)
> > 
> > Under Bookworm with Linux 6.1, the Python script would occasionally
> > freeze, but the VM would remain responsive, and the script would
> > eventually resume. Even with kernel 6.12, both unencrypted
> > swapfiles and swapfiles that are technically unencrypted but live
> > on a LUKS volume both behave as expected. It's only swapfiles that
> > are themselves encrypted that seem to trigger these lockups.
> > 
> > I haven't looked at the code at all, but it seems like maybe memory
> > LUKS needs available in order to operate is being consumed, thus
> > making it impossible to swap anything in and out of the swapfile?
> > That seems like it would cause these symptoms or similar, though I
> > don't know.
> > 
> > Let me know if I can provide any further information on the issue.
> > I'm happy to bisect the kernel if it will help.
> > 
> > --
> > Aaron  
> 


Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists