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] [day] [month] [year] [list]

Message-ID: <Y/fB0mcvwsp/YX4A@bombadil.infradead.org>
Date:   Thu, 23 Feb 2023 11:43:14 -0800
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Christian Brauner <brauner@...nel.org>
Cc:     Christoph Hellwig <hch@...radead.org>, 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 Thu, Feb 23, 2023 at 05:09:14PM +0100, Christian Brauner wrote:
> On Thu, Feb 23, 2023 at 07:16:09AM -0800, Christoph Hellwig wrote:
> > On Thu, Feb 23, 2023 at 01:26:31PM +0100, Christian Brauner wrote:
> > > 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,
> > 
> > What is the advantage of using a swapless tmpfs over ramf?
> 
> There are a few reasons we usually prefer tmpfs over ramfs. Iirc, ramfs
> doesn't have limits and grows dynamically. So we currently only use it
> from the most privileged process where we do our own accounting and
> immediately remount the superblock read-only. Tmpfs on the other hand
> offers various ways to restrict memory consumption.

Size limits is just one bell, in fact ramfs has no configurable options.
So in fact *all* options parsed on shmem_parse_options() are only
available with tmpfs, some of the options are:

  * size
  * number of blocks
  * number of inodes
  * NUMA memory allocation policy
  * huge pages

> Other reasons are that ramfs doesn't support selinux labels, xattrs, and
> acls in general which come in quite handy. Starting with kernel v6.3
> tmpfs does also support idmapped mounts. So we usually always prefer
> ramfs over tmpfs unless we have a very specific need such as the memory
> not being swapped out.

I guess its time to update Documentation/filesystems/tmpfs.rst.

  Luis