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
next prev parent 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