On 11.02.21 10:38, Michal Hocko wrote:
On Thu 11-02-21 10:01:32, David Hildenbrand wrote:
[...]
AFAIKS, we would need MFD_SECRET and disallow
MFD_ALLOW_SEALING and MFD_HUGETLB.
Yes for an initial version. But I do expect a request to support both
features is just a matter of time.
In addition, we could add MFD_SECRET_NEVER_MAP, which could disallow any kind of
temporary mappings (eor migration). TBC.
I believe this is the mode Mike wants to have by default. A more relax
one would be an opt-in. MFD_SECRET_RELAXED which would allow temporal
mappings in the kernel for content copying (e.g. for migration).
---
Some random thoughts regarding files.
What is the page size of secretmem memory? Sometimes we use huge pages,
sometimes we fallback to 4k pages. So I assume huge pages in general?
Unless there is an explicit request for hugetlb I would say the page
size is not really important like for any other fds. Huge pages can be
used transparently.
What are semantics of MADV()/FALLOCATE() etc on such files?
I would expect the same semantic as regular shmem (memfd_create) except
the memory doesn't have _any_ backing storage which makes it
unevictable. So the reclaim related madv won't work but there shouldn't
be any real reason why e.g. MADV_DONTNEED, WILLNEED, DONT_FORK and
others don't work.
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)
--
Thanks,
David / dhildenb
