Re: [PATCH] mm/swap: reject swapon() on filesystem-level encrypted files

[Eric Biggers]

On Thu, Jul 30, 2026 at 12:53:27PM -0700, Andrew Morton wrote:
> On Thu, 30 Jul 2026 11:48:53 -0700 Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
> 
> > ext4 and f2fs don't prevent filesystem-level encrypted files from being
> > set up directly as swap files.  In this case, encryption is bypassed.
> > 
> > No one should be doing this, vs. the methods of encrypted swap that
> > actually do work (such as swapping to a dm-crypt device, or swapping to
> > a loopback device on top of a filesystem-level encrypted file).
> > 
> > Nevertheless, to prevent user error, make swapon() explicitly reject
> > this case.  Document this behavior in fscrypt.rst as well.
> > 
> > Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt support")
> > Fixes: f424f664f0e8 ("f2fs crypto: add encryption policy and password salt support")
> 
> Ouch.  We are going to break ten year old setups?  I don't think we can
> do this!

That assumes anyone is actually depending on this bug, which they
probably aren't.  Encrypted swap is done in other ways.

> I think the best we can do is to emit loud warnings which point the
> operator to some Documentation/ which tells operator that this
> deprecated configuration will be disallowed in, umm, 2029.

... and if they are, they'll want to fix it right away anyway, not in
2029.

Other fixes to explicitly disallow swapfile activation in various cases
have been merged without a deprecation period, e.g. 36e4d95891ed,
377eeaa8e11f, 51cc3a6620a6, d15cab975459.

I think we should try just doing this instead of dragging it out over
several years.

- Eric