linux-kernel - Re: [RFC v2 5/5] shmem: add support to ignore swap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230223122631.hwvhbqxadvbm23nb@wittgenstein>
Date:   Thu, 23 Feb 2023 13:26:31 +0100
From:   Christian Brauner <brauner@...nel.org>
To:     Luis Chamberlain <mcgrof@...nel.org>
Cc:     hughd@...gle.com, akpm@...ux-foundation.org, willy@...radead.org,
        linux-mm@...ck.org, p.raghav@...sung.com, dave@...olabs.net,
        a.manzanares@...sung.com, yosryahmed@...gle.com,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC v2 5/5] shmem: add support to ignore swap

On Wed, Feb 22, 2023 at 06:44:12PM -0800, Luis Chamberlain wrote:
> In doing experimentations with shmem having the option to avoid swap
> becomes a useful mechanism. One of the *raves* about brd over shmem is
> you can avoid swap, but that's not really a good reason to use brd if
> we can instead use shmem. Using brd has its own good reasons to exist,
> but just because "tmpfs" doesn't let you do that is not a great reason
> to avoid it if we can easily add support for it.
> 
> I don't add support for reconfiguring incompatible options, but if
> we really wanted to we can add support for that.
> 
> To avoid swap we use mapping_set_unevictable() upon inode creation,
> and put a WARN_ON_ONCE() stop-gap on writepages() for reclaim.
> 
> Signed-off-by: Luis Chamberlain <mcgrof@...nel.org>
> ---

We would have use-cases for this in systemd. We currently use ramfs for
systemd's credential logic since ramfs is unswappable. It'd be very neat
if we could use tmpfs instead,

Acked-by: Christian Brauner <brauner@...nel.org>