On 07.07.24 02:26, Jason A. Donenfeld wrote:
Hi,
having more generic support for VM_DROPPABLE sounds great, I was myself
at some point looking for something like that.
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
well, giving MAP_WIPEONFORK, MAP_DONTDUMP, and MAP_DROPPABLE.
Patch subject would be better to talk about MAP_DROPPABLE now.
But I don't immediately see why MAP_WIPEONFORK and MAP_DONTDUMP have to
be mmap() flags. Using mmap(MAP_NORESERVE|MAP_DROPPABLE) with madvise()
to configure these (for users that require that) should be good enough,
just like they are for existing users.
Thinking out loud, also MAP_DROPPABLE only sets a VMA flag (and does
snot affect memory commitiing like MAP_NORESERVE), right? So
MAP_DROPPABLE could easily become a madvise() option as well?
(as you know, we only have limited mmap bits but plenty of madvise
numbers available)
Interestingly, when looking into something comparable in the past I
stumbled over "vrange" [1], which would have had a slightly different
semantic (signal on reaccess). And that did turn out to be more sutibale
for madvise() flags [2], whereby vrange evolved into
MADV_VOLATILE/MADV_NONVOLATILE
A sticky MADV_VOLATILE vs. MADV_NONVOLATILE would actually sound pretty
handy. (again, with your semantics, not the signal-on-reaccess kind of
thing)
([2] is in general a good read; hey, it's been 10 years since that was
brought up the last time!)
There needs to be better reasoning why we have to consume three mmap
bits for something that can likely be achieved without any.
Maybe that was discussed with Linus and there is a pretty good reason
for that.
I'll also mention that I am unsure how MAP_DROPPABLE is supposed to
interact with mlock. Maybe just like MADV_FREE currently does (no idea
if that will work as intended ;) ).
[1] https://lwn.net/Articles/590991/
[2] https://lwn.net/Articles/602650/
Finally, the provided self test ensures that this is working as desired.
Cc: linux-mm@xxxxxxxxx
Signed-off-by: Jason A. Donenfeld <Jason@xxxxxxxxx>
---
[...]
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 8c6cd8825273..57b8dad9adcc 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -623,7 +623,7 @@ mprotect_fixup(struct vma_iterator *vmi, struct mmu_gather *tlb,
may_expand_vm(mm, oldflags, nrpages))
return -ENOMEM;
if (!(oldflags & (VM_ACCOUNT|VM_WRITE|VM_HUGETLB|
- VM_SHARED|VM_NORESERVE))) {
+ VM_SHARED|VM_NORESERVE|VM_DROPPABLE))) {
charged = nrpages;
if (security_vm_enough_memory_mm(mm, charged))
return -ENOMEM;
I don't quite understand this change here. If MAP_DROPPABLE does not
affect memory accounting during mmap(), it should not affect the same
during mprotect(). VM_NORESERVE / MAP_NORESERVE is responsible for that.
Did I missing something where MAP_DROPPABLE changes the memory
accounting during mmap()?
diff --git a/mm/rmap.c b/mm/rmap.c
index e8fc5ecb59b2..56d7535d5cf6 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1397,7 +1397,10 @@ void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma,
VM_WARN_ON_FOLIO(folio_test_hugetlb(folio), folio);
VM_BUG_ON_VMA(address < vma->vm_start ||
address + (nr << PAGE_SHIFT) > vma->vm_end, vma);
- __folio_set_swapbacked(folio);
+ /* VM_DROPPABLE mappings don't swap; instead they're just dropped when
+ * under memory pressure. */
+ if (!(vma->vm_flags & VM_DROPPABLE))
+ __folio_set_swapbacked(folio);
__folio_set_anon(folio, vma, address, true);
if (likely(!folio_test_large(folio))) {
@@ -1841,7 +1844,11 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
* plus the rmap(s) (dropped by discard:).
*/
if (ref_count == 1 + map_count &&
- !folio_test_dirty(folio)) {
+ (!folio_test_dirty(folio) ||
+ /* Unlike MADV_FREE mappings, VM_DROPPABLE
+ * ones can be dropped even if they've
+ * been dirtied. */
We use
/*
* Comment start
* Comment end
*/
styled comments in MM.
+ (vma->vm_flags & VM_DROPPABLE))) {
dec_mm_counter(mm, MM_ANONPAGES);
goto discard;
}
@@ -1851,7 +1858,10 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
* discarded. Remap the page to page table.
*/
set_pte_at(mm, address, pvmw.pte, pteval);
- folio_set_swapbacked(folio);
+ /* Unlike MADV_FREE mappings, VM_DROPPABLE ones
+ * never get swap backed on failure to drop. */
+ if (!(vma->vm_flags & VM_DROPPABLE))
+ folio_set_swapbacked(folio);
ret = false;
page_vma_mapped_walk_done(&pvmw);
break;
A note that in mm/mm-stable, "madvise_free_huge_pmd" exists to optimize
MADV_FREE on PMDs. I suspect we'd want to extend that one as well for
dropping support, but likely it would also only be a performance
improvmeent and not affect functonality if not handled.
--
Cheers,
David / dhildenb
