Re: [PATCH v22 1/4] mm: add MAP_DROPPABLE for designating always lazily freeable mappings

[David Hildenbrand]

On 10.07.24 05:27, David Hildenbrand wrote:
> On 09.07.24 15:05, Jason A. Donenfeld wrote:
> > The vDSO getrandom() implementation works with a buffer allocated with a
> > new system call that has certain requirements:
> >
> > - It shouldn't be written to core dumps.
> >     * Easy: VM_DONTDUMP.
> > - It should be zeroed on fork.
> >     * Easy: VM_WIPEONFORK.
> >
> > - It shouldn't be written to swap.
> >     * Uh-oh: mlock is rlimited.
> >     * Uh-oh: mlock isn't inherited by forks.
> >
> > It turns out that the vDSO getrandom() function has three really nice
> > characteristics that we can exploit to solve this problem:
> >
> > 1) Due to being wiped during fork(), the vDSO code is already robust to
> >      having the contents of the pages it reads zeroed out midway through
> >      the function's execution.
> >
> > 2) In the absolute worst case of whatever contingency we're coding for,
> >      we have the option to fallback to the getrandom() syscall, and
> >      everything is fine.
> >
> > 3) The buffers the function uses are only ever useful for a maximum of
> >      60 seconds -- a sort of cache, rather than a long term allocation.
> >
> > These characteristics mean that we can introduce VM_DROPPABLE, which
> > has the following semantics:
> >
> > a) It never is written out to swap.
> > b) Under memory pressure, mm can just drop the pages (so that they're
> >      zero when read back again).
> > c) It is inherited by fork.
> > d) It doesn't count against the mlock budget, since nothing is locked.
> >
> > This is fairly simple to implement, with the one snag that we have to
> > use 64-bit VM_* flags, but this shouldn't be a problem, since the only
> > consumers will probably be 64-bit anyway.
> >
> > This way, allocations used by vDSO getrandom() can use:
> >
> >       VM_DROPPABLE | VM_DONTDUMP | VM_WIPEONFORK | VM_NORESERVE
> >
> > And there will be no problem with using memory when not in use, not
> > wiping on fork(), coredumps, or writing out to swap.
> >
> > In order to let vDSO getrandom() use this, expose these via mmap(2) as
> > MAP_DROPPABLE.
> >
> > Finally, the provided self test ensures that this is working as desired.
>
> Acked-by: David Hildenbrand <david@xxxxxxxxxx>
>
>
> I'll try to think of some corner cases we might be missing.

Sorry that I keep coming up with corner cases :) But these should be easy to handle:

1) We should disallow KSM.

diff --git a/mm/ksm.c b/mm/ksm.c
index df6bae3a5a2c..d6744183ba41 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -713,7 +713,7 @@ static bool vma_ksm_compatible(struct vm_area_struct *vma)
 {
        if (vma->vm_flags & (VM_SHARED  | VM_MAYSHARE   | VM_PFNMAP  |
                             VM_IO      | VM_DONTEXPAND | VM_HUGETLB |
-                            VM_MIXEDMAP))
+                            VM_MIXEDMAP | VM_DROPPABLE))
                return false;           /* just ignore the advice */
 
        if (vma_is_dax(vma))


We don't want to suddenly get pages that are swapbacked.


2) We should disable userfaultfd

diff --git a/include/linux/userfaultfd_k.h b/include/linux/userfaultfd_k.h
index 05d59f74fc88..a12bcf042551 100644
--- a/include/linux/userfaultfd_k.h
+++ b/include/linux/userfaultfd_k.h
@@ -218,6 +218,9 @@ static inline bool vma_can_userfault(struct vm_area_struct *vma,
 {
        vm_flags &= __VM_UFFD_FLAGS;
 
+       if (vm_flags & VM_DROPPABLE)
+               return false;
+
        if ((vm_flags & VM_UFFD_MINOR) &&
            (!is_vm_hugetlb_page(vma) && !vma_is_shmem(vma)))
                return false;


Otherwise someone could place swapbacked pages in there (using UFFDIO_MOVE)
I think. But conceptually, I don't think userfaultfd might not make sense at
all with uffd. And if there are good reasons for it in the future, we could
enable the parts that make sense.


I think other places like khugepaged should handle it correctly (not set
swapbacked) due to your changes to folio_add_new_anon_rmap().

--
Cheers,

David / dhildenb