linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: Kurt Fitzner <kurt_cryptsetup@va1der.ca>
Cc: Aaron Rainbolt <arraybolt3@gmail.com>,
	Milan Broz <gmazyland@gmail.com>,
	 linux-mm@kvack.org, cryptsetup@lists.linux.dev,
	dm-devel@lists.linux.dev,  linux-kernel@vger.kernel.org,
	adrelanos@whonix.org
Subject: Re: Hard system lock-ups when using encrypted swap and RAM is exhausted
Date: Fri, 28 Nov 2025 14:06:54 +0100 (CET)	[thread overview]
Message-ID: <32c2c4c6-d8c0-297a-b0eb-f06a939d5e44@redhat.com> (raw)
In-Reply-To: <804601778974c504d42f4423d335a94d@va1der.ca>



On Thu, 27 Nov 2025, Kurt Fitzner wrote:

> On 2025-11-27 13:54, Mikulas Patocka wrote:
> 
> > Encrypted swap file is not supposed to work.
> 
> Do you have a reference for this?  The concept of encrypted swap files has
> been a valid workflow for a very long time.
> 
> > 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.
> 
> If it's the filesystem trying to allocate memory on writes to a swap file that
> is causing a memory allocation/swap race, then any write to a swap file would
> engender the same result, regardless of encryption. The encryption layer is
> redundant under the failure mode you propose.

No - when you swap to unencrypted file, the kernel bypasses the 
filesystem. It creates a block map of the file at swap activation time and 
when it swaps to the file it uses this block map and it doesn't call any 
filesystem functions.

This bypass doesn't work when you put other block device drivers over the 
file.

> I can confirm I have put kernels up to and including 6.14 under heavy memory
> stress and have never encountered anything that feels like a memory allocation
> race.  All my systems have encrypted swap files.
> 
> I can't speak toward later kernels, or any bugs that may or may not be
> presesnt, but I know of nothing to suggest that encrypted swap files remain
> anything other than an intended feature.
> 
>     Kurt

So, it works by chance, not by design.

Mikulas



  reply	other threads:[~2025-11-28 13:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-12  5:18 Aaron Rainbolt
2025-11-27  7:59 ` Milan Broz
2025-11-27 17:54   ` Mikulas Patocka
2025-11-27 23:24     ` Aaron Rainbolt
2025-11-28  0:51     ` Kurt Fitzner
2025-11-28 13:06       ` Mikulas Patocka [this message]
2025-11-27 23:37   ` Aaron Rainbolt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32c2c4c6-d8c0-297a-b0eb-f06a939d5e44@redhat.com \
    --to=mpatocka@redhat.com \
    --cc=adrelanos@whonix.org \
    --cc=arraybolt3@gmail.com \
    --cc=cryptsetup@lists.linux.dev \
    --cc=dm-devel@lists.linux.dev \
    --cc=gmazyland@gmail.com \
    --cc=kurt_cryptsetup@va1der.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox