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

David Hildenbrand
2024-07-11T22:29:23Z

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@redhat.com>
>
>
> 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