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

[David Hildenbrand]

> > 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.

If everything is currently allocated/mapped on PTE granularity, then yes 
I agree. I remember previous versions used to "pool 2MB pages", which 
might have been problematic (thus, my concerns regarding mmap() etc.). 
If that part is now gone, good!

>   
> > 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.

Agreed if we don't have hugepage semantics.

> > Is userfaultfd() properly fenced? Or does it even work (doubt)?
> >
> > How does it behave if I mmap(FIXED) something in between?
> > In which granularity can I do that (->page-size?)?
>
> Again, nothing really exceptional here. This is a mapping like any
> other from address space manipulation POV.

Agreed with the PTE mapping approach.

> > What are other granularity restrictions (->page size)?
> >
> > Don't want to open a big discussion here, just some random thoughts.
> > Maybe it has all been already figured out and most of the answers
> > above are "Fails with -EINVAL".
>
> I think that the behavior should be really in sync with shmem semantic
> as much as possible. Most operations should simply work with an
> aditional direct map manipulation. There is no real reason to be
> special. Some functionality might be missing, e.g. hugetlb support but
> that has been traditionally added on top of shmem interface so nothing
> really new here.

Agreed!

--
Thanks,

David / dhildenb