Thread (73 messages) 73 messages, 7 authors, 2021-02-22

Re: [PATCH v17 07/10] mm: introduce memfd_secret system call to create "secret" memory areas

From: Mike Rapoport <rppt@kernel.org>
Date: 2021-02-11 11:34:46
Also in: linux-api, linux-arch, linux-arm-kernel, linux-fsdevel, linux-kselftest, linux-riscv, lkml, nvdimm

On Thu, Feb 11, 2021 at 11:02:07AM +0100, David Hildenbrand wrote:
Another thought regarding "doesn't have _any_ backing storage"

What are the right semantics when it comes to memory accounting/commit?

As secretmem does not have
a) any backing storage
b) cannot go to swap

The MAP_NORESERVE vs. !MAP_NORESERVE handling gets a little unclear. Why
"reserve swap space" if the allocations cannot ever go to swap? Sure, we
want to "reserve physical memory", but in contrast to other users that can
go to swap.

Of course, this is only relevant for MAP_PRIVATE secretmem mappings. Other
MAP_SHARED assumes there is no need for reserving swap space as it can just
go to the backing storage. (yeah, tmpfs/shmem is weird in that regard as
well, but again, it's a bit different)
In that sense seceremem is as weird as tmpfs and it only allows MAP_SHARED.

-- 
Sincerely yours,
Mike.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help