| Message ID | 20240709130513.98102-1-Jason@zx2c4.com |
|---|---|
| Headers | show |
| Series | implement getrandom() in vDSO | expand |
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. As raised, I think we could do better at naming, such as "MAP_FREEABLE" to match MADV_FREE, MAP_VOLATILE, ... but if nobody else care, I shall not care :)
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. BTW, do we have to handle the folio_set_swapbacked() in sort_folio() as well? /* dirty lazyfree */ if (type == LRU_GEN_FILE && folio_test_anon(folio) && folio_test_dirty(folio)) { success = lru_gen_del_folio(lruvec, folio, true); VM_WARN_ON_ONCE_FOLIO(!success, folio); folio_set_swapbacked(folio); lruvec_add_folio_tail(lruvec, folio); return true; } Maybe more difficult because we don't have a VMA here ... hmm IIUC, we have to make sure that no folio_set_swapbacked() would ever get performed on these folios, correct?
Hi David, On Wed, Jul 10, 2024 at 06:05:34AM +0200, David Hildenbrand wrote: > BTW, do we have to handle the folio_set_swapbacked() in sort_folio() as well? > > > /* dirty lazyfree */ > if (type == LRU_GEN_FILE && folio_test_anon(folio) && folio_test_dirty(folio)) { > success = lru_gen_del_folio(lruvec, folio, true); > VM_WARN_ON_ONCE_FOLIO(!success, folio); > folio_set_swapbacked(folio); > lruvec_add_folio_tail(lruvec, folio); > return true; > } > > Maybe more difficult because we don't have a VMA here ... hmm > > IIUC, we have to make sure that no folio_set_swapbacked() would ever get > performed on these folios, correct? Hmmm, I'm trying to figure out what to do here, and if we have to do something. All three conditions in that if statement will be true for a folio in a droppable mapping. That's supposed to match MADV_FREE mappings. What is the context of this, though? It's scanning pages for good ones to evict into swap, right? So if it encounters one that's an MADV_FREE page, it actually just wants to delete it, rather than sending it to swap. So it looks like it does just that, and then sets the swapbacked bit back to true, in case the folio is used for something differnet later? If that's correct, then I don't think we need to do anything for this one. If that's not correct, then we'll need to propagate the droppableness to the folio level. But hopefully we don't need to do that. What's your analysis of this like? Jason
On Thu, Jul 11, 2024 at 02:44:29AM +0200, Jason A. Donenfeld wrote: > Hi David, > > On Wed, Jul 10, 2024 at 06:05:34AM +0200, David Hildenbrand wrote: > > BTW, do we have to handle the folio_set_swapbacked() in sort_folio() as well? > > > > > > /* dirty lazyfree */ > > if (type == LRU_GEN_FILE && folio_test_anon(folio) && folio_test_dirty(folio)) { > > success = lru_gen_del_folio(lruvec, folio, true); > > VM_WARN_ON_ONCE_FOLIO(!success, folio); > > folio_set_swapbacked(folio); > > lruvec_add_folio_tail(lruvec, folio); > > return true; > > } > > > > Maybe more difficult because we don't have a VMA here ... hmm > > > > IIUC, we have to make sure that no folio_set_swapbacked() would ever get > > performed on these folios, correct? > > Hmmm, I'm trying to figure out what to do here, and if we have to do > something. All three conditions in that if statement will be true for a > folio in a droppable mapping. That's supposed to match MADV_FREE > mappings. > > What is the context of this, though? It's scanning pages for good ones > to evict into swap, right? So if it encounters one that's an MADV_FREE > page, it actually just wants to delete it, rather than sending it to > swap. So it looks like it does just that, and then sets the swapbacked > bit back to true, in case the folio is used for something differnet > later? > > If that's correct, then I don't think we need to do anything for this > one. > > If that's not correct, then we'll need to propagate the droppableness > to the folio level. But hopefully we don't need to do that. Looks like that's not correct. This is for pages that have been dirtied since calling MADV_FREE. So, hm.
On 11.07.24 06:32, Jason A. Donenfeld wrote: > On Thu, Jul 11, 2024 at 02:44:29AM +0200, Jason A. Donenfeld wrote: >> Hi David, >> >> On Wed, Jul 10, 2024 at 06:05:34AM +0200, David Hildenbrand wrote: >>> BTW, do we have to handle the folio_set_swapbacked() in sort_folio() as well? >>> >>> >>> /* dirty lazyfree */ >>> if (type == LRU_GEN_FILE && folio_test_anon(folio) && folio_test_dirty(folio)) { >>> success = lru_gen_del_folio(lruvec, folio, true); >>> VM_WARN_ON_ONCE_FOLIO(!success, folio); >>> folio_set_swapbacked(folio); >>> lruvec_add_folio_tail(lruvec, folio); >>> return true; >>> } >>> >>> Maybe more difficult because we don't have a VMA here ... hmm >>> >>> IIUC, we have to make sure that no folio_set_swapbacked() would ever get >>> performed on these folios, correct? >> >> Hmmm, I'm trying to figure out what to do here, and if we have to do >> something. All three conditions in that if statement will be true for a >> folio in a droppable mapping. That's supposed to match MADV_FREE >> mappings. >> >> What is the context of this, though? It's scanning pages for good ones >> to evict into swap, right? So if it encounters one that's an MADV_FREE >> page, it actually just wants to delete it, rather than sending it to >> swap. So it looks like it does just that, and then sets the swapbacked >> bit back to true, in case the folio is used for something differnet >> later? >> >> If that's correct, then I don't think we need to do anything for this >> one. >> >> If that's not correct, then we'll need to propagate the droppableness >> to the folio level. But hopefully we don't need to do that. > > Looks like that's not correct. This is for pages that have been dirtied > since calling MADV_FREE. So, hm. > Maybe we can find ways of simply never marking these pages dirty, so we don't have to special-case that code where we don't really have a VMA at hand?
On Wed, 10 Jul 2024 at 21:46, David Hildenbrand <david@redhat.com> wrote: > > Maybe we can find ways of simply never marking these pages dirty, so we > don't have to special-case that code where we don't really have a VMA at > hand? That's one option. Jason's patch basically goes "ignore folio dirty bit for these pages". Your suggestion basically says "don't turn folios dirty in the first place". It's mainly the pte_dirty games in mm/vmscan.c that does it (walk_pte_range), but also the tear-down in mm/memory.c (zap_present_folio_ptes). Possibly others that I didn't think of. Both do have access to the vma, although in the case of walk_pte_range() we don't actually pass it down because we haven't needed it). There's also page_vma_mkclean_one(), try_to_unmap_one() and try_to_migrate_one(). And possibly many others I haven't even thought about. So quite a few places that do that "transfer dirty bit from pte to folio". The other approach might be to just let all the dirty handling happen - make droppable pages have a "page->mapping" (and not be anonymous), and have the mapping->a_ops->writepage() just always return success immediately. That might actually be a conceptually simpler model. MAP_DROPPABLE becomes a shared mapping that just has a really cheap writeback that throws the data away. No need to worry about swap cache or anything like that, because that's just for anonymous pages. I say "conceptually simpler", because right now the patch does depend on just using the regular anon page faulting etc code. Linus
Hi Linus, David, On Wed, Jul 10, 2024 at 10:07:03PM -0700, Linus Torvalds wrote: > The other approach might be to just let all the dirty handling happen > - make droppable pages have a "page->mapping" (and not be anonymous), > and have the mapping->a_ops->writepage() just always return success > immediately. When I was working on this patchset this year with the syscall, this is similar somewhat to the initial approach I was taking with setting up a special mapping. It turned into kind of a mess and I couldn't get it working. There's a lot of functionality built around anonymous pages that would need to be duplicated (I think?). I'll revisit it if need be, but let's see if I can make avoiding the dirty bit propagation work. > It's mainly the pte_dirty games in mm/vmscan.c that does it > (walk_pte_range), but also the tear-down in mm/memory.c > (zap_present_folio_ptes). Possibly others that I didn't think of. > > Both do have access to the vma, although in the case of > walk_pte_range() we don't actually pass it down because we haven't > needed it). Actually, it's there hanging out in args->vma, and the function makes use of that member already. So not so bad. > > There's also page_vma_mkclean_one(), try_to_unmap_one() and > try_to_migrate_one(). And possibly many others I haven't even thought > about. > > So quite a few places that do that "transfer dirty bit from pte to folio". Alright, an hour later of fiddling, and it doesn't actually work (yet?) -- the selftest fails. A diff follows below. So, hmm... The swapbacked thing really seemed so simple... I wonder if there's a way of recovering that. Jason diff --git a/mm/gup.c b/mm/gup.c index ca0f5cedce9b..38745cc4fa06 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -990,7 +990,8 @@ static struct page *follow_page_pte(struct vm_area_struct *vma, } if (flags & FOLL_TOUCH) { if ((flags & FOLL_WRITE) && - !pte_dirty(pte) && !PageDirty(page)) + !pte_dirty(pte) && !PageDirty(page) && + !(vma->vm_flags & VM_DROPPABLE)) set_page_dirty(page); /* * pte_mkyoung() would be more correct here, but atomic care diff --git a/mm/ksm.c b/mm/ksm.c index 34c4820e0d3d..2401fc4203ba 100644 --- a/mm/ksm.c +++ b/mm/ksm.c @@ -1339,7 +1339,7 @@ static int write_protect_page(struct vm_area_struct *vma, struct folio *folio, goto out_unlock; } - if (pte_dirty(entry)) + if (pte_dirty(entry) && !(vma->vm_flags & VM_DROPPABLE)) folio_mark_dirty(folio); entry = pte_mkclean(entry); @@ -1518,7 +1518,7 @@ static int try_to_merge_one_page(struct vm_area_struct *vma, * Page reclaim just frees a clean page with no dirty * ptes: make sure that the ksm page would be swapped. */ - if (!PageDirty(page)) + if (!PageDirty(page) && !(vma->vm_flags & VM_DROPPABLE)) SetPageDirty(page); err = 0; } else if (pages_identical(page, kpage)) diff --git a/mm/memory.c b/mm/memory.c index d10e616d7389..6a02d16309be 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -1479,7 +1479,7 @@ static __always_inline void zap_present_folio_ptes(struct mmu_gather *tlb, if (!folio_test_anon(folio)) { ptent = get_and_clear_full_ptes(mm, addr, pte, nr, tlb->fullmm); - if (pte_dirty(ptent)) { + if (pte_dirty(ptent) && !(vma->vm_flags & VM_DROPPABLE)) { folio_mark_dirty(folio); if (tlb_delay_rmap(tlb)) { delay_rmap = true; @@ -6140,7 +6140,8 @@ static int __access_remote_vm(struct mm_struct *mm, unsigned long addr, if (write) { copy_to_user_page(vma, page, addr, maddr + offset, buf, bytes); - set_page_dirty_lock(page); + if (!(vma->vm_flags & VM_DROPPABLE)) + set_page_dirty_lock(page); } else { copy_from_user_page(vma, page, addr, buf, maddr + offset, bytes); diff --git a/mm/migrate_device.c b/mm/migrate_device.c index aecc71972a87..72d3f8eaae6e 100644 --- a/mm/migrate_device.c +++ b/mm/migrate_device.c @@ -216,7 +216,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp, migrate->cpages++; /* Set the dirty flag on the folio now the pte is gone. */ - if (pte_dirty(pte)) + if (pte_dirty(pte) && !(vma->vm_flags & VM_DROPPABLE)) folio_mark_dirty(folio); /* Setup special migration page table entry */ diff --git a/mm/rmap.c b/mm/rmap.c index 1f9b5a9cb121..1688d06bb617 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -1397,12 +1397,7 @@ 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); - /* - * 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_swapbacked(folio); __folio_set_anon(folio, vma, address, true); if (likely(!folio_test_large(folio))) { @@ -1777,7 +1772,7 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, pte_install_uffd_wp_if_needed(vma, address, pvmw.pte, pteval); /* Set the dirty flag on the folio now the pte is gone. */ - if (pte_dirty(pteval)) + if (pte_dirty(pteval) && !(vma->vm_flags & VM_DROPPABLE)) folio_mark_dirty(folio); /* Update high watermark before we lower rss */ @@ -1822,7 +1817,7 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, } /* MADV_FREE page check */ - if (!folio_test_swapbacked(folio)) { + if (!folio_test_swapbacked(folio) || (vma->vm_flags & VM_DROPPABLE)) { int ref_count, map_count; /* @@ -1846,13 +1841,7 @@ 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) || - /* - * Unlike MADV_FREE mappings, VM_DROPPABLE - * ones can be dropped even if they've - * been dirtied. - */ - (vma->vm_flags & VM_DROPPABLE))) { + !folio_test_dirty(folio)) { dec_mm_counter(mm, MM_ANONPAGES); goto discard; } @@ -1862,12 +1851,7 @@ 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); - /* - * 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); + folio_set_swapbacked(folio); ret = false; page_vma_mapped_walk_done(&pvmw); break; @@ -2151,7 +2135,7 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma, } /* Set the dirty flag on the folio now the pte is gone. */ - if (pte_dirty(pteval)) + if (pte_dirty(pteval) && !(vma->vm_flags & VM_DROPPABLE)) folio_mark_dirty(folio); /* Update high watermark before we lower rss */ @@ -2397,7 +2381,7 @@ static bool page_make_device_exclusive_one(struct folio *folio, pteval = ptep_clear_flush(vma, address, pvmw.pte); /* Set the dirty flag on the folio now the pte is gone. */ - if (pte_dirty(pteval)) + if (pte_dirty(pteval) && !(vma->vm_flags & VM_DROPPABLE)) folio_mark_dirty(folio); /* diff --git a/mm/vmscan.c b/mm/vmscan.c index 2e34de9cd0d4..cf5b26bd067a 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -3396,6 +3396,7 @@ static bool walk_pte_range(pmd_t *pmd, unsigned long start, unsigned long end, walk->mm_stats[MM_LEAF_YOUNG]++; if (pte_dirty(ptent) && !folio_test_dirty(folio) && + !(args->vma->vm_flags & VM_DROPPABLE) && !(folio_test_anon(folio) && folio_test_swapbacked(folio) && !folio_test_swapcache(folio))) folio_mark_dirty(folio); @@ -3476,6 +3477,7 @@ static void walk_pmd_range_locked(pud_t *pud, unsigned long addr, struct vm_area walk->mm_stats[MM_LEAF_YOUNG]++; if (pmd_dirty(pmd[i]) && !folio_test_dirty(folio) && + !(vma->vm_flags && VM_DROPPABLE) && !(folio_test_anon(folio) && folio_test_swapbacked(folio) && !folio_test_swapcache(folio))) folio_mark_dirty(folio); @@ -4076,6 +4078,7 @@ void lru_gen_look_around(struct page_vma_mapped_walk *pvmw) young++; if (pte_dirty(ptent) && !folio_test_dirty(folio) && + !(vma->vm_flags & VM_DROPPABLE) && !(folio_test_anon(folio) && folio_test_swapbacked(folio) && !folio_test_swapcache(folio))) folio_mark_dirty(folio);
On Thu, Jul 11, 2024 at 07:09:36PM +0200, Jason A. Donenfeld wrote: > So, hmm... The swapbacked thing really seemed so simple... I wonder if > there's a way of recovering that. Not wanting to introduce a new bitflag, I went looking and noticed this: /* * Private page markings that may be used by the filesystem that owns the page * for its own purposes. * - PG_private and PG_private_2 cause release_folio() and co to be invoked */ PAGEFLAG(Private, private, PF_ANY) PAGEFLAG(Private2, private_2, PF_ANY) TESTSCFLAG(Private2, private_2, PF_ANY) PAGEFLAG(OwnerPriv1, owner_priv_1, PF_ANY) TESTCLEARFLAG(OwnerPriv1, owner_priv_1, PF_ANY) The below +4/-1 diff is pretty hacky and might be illegal in the state of California, but I think it does work. The idea is that if that bit is normally only used for filesystems, then in the anonymous case, it's free to be used for this. Any opinions about this, or a suggestion on how to do that in a less ugly way? Jason diff --git a/mm/rmap.c b/mm/rmap.c index 1f9b5a9cb121..090554277e4a 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -1403,6 +1403,8 @@ void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma, */ if (!(vma->vm_flags & VM_DROPPABLE)) __folio_set_swapbacked(folio); + else + folio_set_owner_priv_1(folio); __folio_set_anon(folio, vma, address, true); if (likely(!folio_test_large(folio))) { diff --git a/mm/vmscan.c b/mm/vmscan.c index 2e34de9cd0d4..398b46027e8f 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4266,7 +4266,8 @@ static bool sort_folio(struct lruvec *lruvec, struct folio *folio, struct scan_c } /* dirty lazyfree */ - if (type == LRU_GEN_FILE && folio_test_anon(folio) && folio_test_dirty(folio)) { + if (type == LRU_GEN_FILE && folio_test_anon(folio) && + folio_test_dirty(folio) && !folio_test_owner_priv_1(folio)) { success = lru_gen_del_folio(lruvec, folio, true); VM_WARN_ON_ONCE_FOLIO(!success, folio); folio_set_swapbacked(folio);
On 11.07.24 19:17, Jason A. Donenfeld wrote: > On Thu, Jul 11, 2024 at 07:09:36PM +0200, Jason A. Donenfeld wrote: >> So, hmm... The swapbacked thing really seemed so simple... I wonder if >> there's a way of recovering that. > > Not wanting to introduce a new bitflag, I went looking and noticed this: > > /* > * Private page markings that may be used by the filesystem that owns the page > * for its own purposes. > * - PG_private and PG_private_2 cause release_folio() and co to be invoked > */ > PAGEFLAG(Private, private, PF_ANY) > PAGEFLAG(Private2, private_2, PF_ANY) TESTSCFLAG(Private2, private_2, PF_ANY) > PAGEFLAG(OwnerPriv1, owner_priv_1, PF_ANY) > TESTCLEARFLAG(OwnerPriv1, owner_priv_1, PF_ANY) > > The below +4/-1 diff is pretty hacky and might be illegal in the state > of California, but I think it does work. The idea is that if that bit is > normally only used for filesystems, then in the anonymous case, it's > free to be used for this. > > Any opinions about this, or a suggestion on how to do that in a less > ugly way? > > Jason > > > diff --git a/mm/rmap.c b/mm/rmap.c > index 1f9b5a9cb121..090554277e4a 100644 > --- a/mm/rmap.c > +++ b/mm/rmap.c > @@ -1403,6 +1403,8 @@ void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma, > */ > if (!(vma->vm_flags & VM_DROPPABLE)) > __folio_set_swapbacked(folio); > + else > + folio_set_owner_priv_1(folio); PG_owner_priv_1 maps to PG_swapcache? :)
On 11.07.24 19:24, David Hildenbrand wrote: > On 11.07.24 19:17, Jason A. Donenfeld wrote: >> On Thu, Jul 11, 2024 at 07:09:36PM +0200, Jason A. Donenfeld wrote: >>> So, hmm... The swapbacked thing really seemed so simple... I wonder if >>> there's a way of recovering that. >> >> Not wanting to introduce a new bitflag, I went looking and noticed this: >> >> /* >> * Private page markings that may be used by the filesystem that owns the page >> * for its own purposes. >> * - PG_private and PG_private_2 cause release_folio() and co to be invoked >> */ >> PAGEFLAG(Private, private, PF_ANY) >> PAGEFLAG(Private2, private_2, PF_ANY) TESTSCFLAG(Private2, private_2, PF_ANY) >> PAGEFLAG(OwnerPriv1, owner_priv_1, PF_ANY) >> TESTCLEARFLAG(OwnerPriv1, owner_priv_1, PF_ANY) >> >> The below +4/-1 diff is pretty hacky and might be illegal in the state >> of California, but I think it does work. The idea is that if that bit is >> normally only used for filesystems, then in the anonymous case, it's >> free to be used for this. >> >> Any opinions about this, or a suggestion on how to do that in a less >> ugly way? >> >> Jason >> >> >> diff --git a/mm/rmap.c b/mm/rmap.c >> index 1f9b5a9cb121..090554277e4a 100644 >> --- a/mm/rmap.c >> +++ b/mm/rmap.c >> @@ -1403,6 +1403,8 @@ void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma, >> */ >> if (!(vma->vm_flags & VM_DROPPABLE)) >> __folio_set_swapbacked(folio); >> + else >> + folio_set_owner_priv_1(folio); > > > PG_owner_priv_1 maps to PG_swapcache? :) Maybe the combination !swapbacked && swapcache could be used to indicate such folios. (we will never set swapbacked) But likely we have to be a bit careful here. We don't want folio_test_swapcache() to return for folios that ... are not in the swapcache.
On Thu, Jul 11, 2024 at 07:24:33PM +0200, David Hildenbrand wrote: > On 11.07.24 19:17, Jason A. Donenfeld wrote: > > On Thu, Jul 11, 2024 at 07:09:36PM +0200, Jason A. Donenfeld wrote: > >> So, hmm... The swapbacked thing really seemed so simple... I wonder if > >> there's a way of recovering that. > > > > Not wanting to introduce a new bitflag, I went looking and noticed this: > > > > /* > > * Private page markings that may be used by the filesystem that owns the page > > * for its own purposes. > > * - PG_private and PG_private_2 cause release_folio() and co to be invoked > > */ > > PAGEFLAG(Private, private, PF_ANY) > > PAGEFLAG(Private2, private_2, PF_ANY) TESTSCFLAG(Private2, private_2, PF_ANY) > > PAGEFLAG(OwnerPriv1, owner_priv_1, PF_ANY) > > TESTCLEARFLAG(OwnerPriv1, owner_priv_1, PF_ANY) > > > > The below +4/-1 diff is pretty hacky and might be illegal in the state > > of California, but I think it does work. The idea is that if that bit is > > normally only used for filesystems, then in the anonymous case, it's > > free to be used for this. > > > > Any opinions about this, or a suggestion on how to do that in a less > > ugly way? > > > > Jason > > > > > > diff --git a/mm/rmap.c b/mm/rmap.c > > index 1f9b5a9cb121..090554277e4a 100644 > > --- a/mm/rmap.c > > +++ b/mm/rmap.c > > @@ -1403,6 +1403,8 @@ void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma, > > */ > > if (!(vma->vm_flags & VM_DROPPABLE)) > > __folio_set_swapbacked(folio); > > + else > > + folio_set_owner_priv_1(folio); > > > PG_owner_priv_1 maps to PG_swapcache? :) Oh, drat, it looks like this overloading is nothing new then.
On Thu, Jul 11, 2024 at 07:27:27PM +0200, David Hildenbrand wrote: > > PG_owner_priv_1 maps to PG_swapcache? :) > > Maybe the combination !swapbacked && swapcache could be used to indicate > such folios. (we will never set swapbacked) > > But likely we have to be a bit careful here. We don't want > folio_test_swapcache() to return for folios that ... are not in the > swapcache. I was thinking that too, but I'm afraid it's going to be another whack-a-mole nightmare. Even for things like task_mmu in procfs that show stats, that's going to be wonky. Any other flags we can overload that aren't going to be already used in our case? Jason
On Thu, Jul 11, 2024 at 07:54:34PM +0200, Jason A. Donenfeld wrote: > On Thu, Jul 11, 2024 at 07:27:27PM +0200, David Hildenbrand wrote: > > > PG_owner_priv_1 maps to PG_swapcache? :) > > > > Maybe the combination !swapbacked && swapcache could be used to indicate > > such folios. (we will never set swapbacked) > > > > But likely we have to be a bit careful here. We don't want > > folio_test_swapcache() to return for folios that ... are not in the > > swapcache. > > I was thinking that too, but I'm afraid it's going to be another > whack-a-mole nightmare. Even for things like task_mmu in procfs that > show stats, that's going to be wonky. > > Any other flags we can overload that aren't going to be already used in > our case? PG_error / folio_set_error seems unused in the non-IO case.
On Thu, 11 Jul 2024 at 10:09, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > When I was working on this patchset this year with the syscall, this is > similar somewhat to the initial approach I was taking with setting up a > special mapping. It turned into kind of a mess and I couldn't get it > working. There's a lot of functionality built around anonymous pages > that would need to be duplicated (I think?). Yeah, I was kind of assuming that. You'd need to handle VM_DROPPABLE in the fault path specially, the way we currently split up based on vma_is_anonymous(), eg if (vma_is_anonymous(vmf->vma)) return do_anonymous_page(vmf); else return do_fault(vmf); in do_pte_missing() etc. I don't actually think it would be too hard, but it's a more "conceptual" change, and it's probably not worth it. > Alright, an hour later of fiddling, and it doesn't actually work (yet?) > -- the selftest fails. A diff follows below. May I suggest a slightly different approach: do what we did for "pte_mkwrite()". It needed the vma too, for not too dissimilar reasons: special dirty bit handling for the shadow stack. See bb3aadf7d446 ("x86/mm: Start actually marking _PAGE_SAVED_DIRTY") b497e52ddb2a ("x86/mm: Teach pte_mkwrite() about stack memory") and now we have "pte_mkwrite_novma()" with the old semantics for the legacy cases that didn't get converted - whether it's because the architecture doesn't have the issue, or because it's a kernel pte. And the conversion was actually quite pain-free, because we have #ifndef pte_mkwrite static inline pte_t pte_mkwrite(pte_t pte, struct vm_area_struct *vma) { return pte_mkwrite_novma(pte); } #endif so all any architecture that didn't want this needed to do was to rename their pte_mkwrite() to pte_mkwrite_novma() and they were done. In fact, that was done first as basically semantically no-op patches: 2f0584f3f4bd ("mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()") 6ecc21bb432d ("mm: Move pte/pmd_mkwrite() callers with no VMA to _novma()") 161e393c0f63 ("mm: Make pte_mkwrite() take a VMA") which made this all very pain-free (and was largely a sed script, I think). > - !pte_dirty(pte) && !PageDirty(page)) > + !pte_dirty(pte) && !PageDirty(page) && > + !(vma->vm_flags & VM_DROPPABLE)) So instead of this kind of thing, we'd have > - !pte_dirty(pte) && !PageDirty(page)) > + !pte_dirty(pte, vma) && !PageDirty(page) && and the advantage here is that you can't miss anybody by mistake. The compiler will be very unhappy if you don't pass in the vma, and then any places that would be converted to "pte_dirty_novma()" We don't actually have all that many users of pte_dirty(), so it doesn't look too nasty. And if we make the pte_dirty() semantics depend on the vma, I really think we should do it the same way we did pte_mkwrite(). Long-term, maybe we should just aim to always pass in the vma to the pte_xyz() functions, but... Linus
On 11.07.24 20:08, Jason A. Donenfeld wrote: > On Thu, Jul 11, 2024 at 07:56:39PM +0200, Jason A. Donenfeld wrote: >> On Thu, Jul 11, 2024 at 07:54:34PM +0200, Jason A. Donenfeld wrote: >>> On Thu, Jul 11, 2024 at 07:27:27PM +0200, David Hildenbrand wrote: >>>>> PG_owner_priv_1 maps to PG_swapcache? :) >>>> >>>> Maybe the combination !swapbacked && swapcache could be used to indicate >>>> such folios. (we will never set swapbacked) >>>> >>>> But likely we have to be a bit careful here. We don't want >>>> folio_test_swapcache() to return for folios that ... are not in the >>>> swapcache. >>> >>> I was thinking that too, but I'm afraid it's going to be another >>> whack-a-mole nightmare. Even for things like task_mmu in procfs that >>> show stats, that's going to be wonky. >>> >>> Any other flags we can overload that aren't going to be already used in >>> our case? >> >> PG_error / folio_set_error seems unused in the non-IO case. > Note that Willy is about to remove PG_error IIRC. > And PG_large_rmappable seems to only be used for hugetlb branches. It should be set for THP/large folios.
On 11.07.24 20:54, Jason A. Donenfeld wrote: > On Thu, Jul 11, 2024 at 08:24:07PM +0200, David Hildenbrand wrote: >>> And PG_large_rmappable seems to only be used for hugetlb branches. >> >> It should be set for THP/large folios. > > And it's tested too, apparently. > > Okay, well, how disappointing is this below? Because I'm running out of > tricks for flag reuse. > > diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h > index b9e914e1face..c1ea49a7f198 100644 > --- a/include/linux/page-flags.h > +++ b/include/linux/page-flags.h > @@ -110,6 +110,7 @@ enum pageflags { > PG_workingset, > PG_error, > PG_owner_priv_1, /* Owner use. If pagecache, fs may use*/ > + PG_owner_priv_2, Oh no, no new page flags please :) Maybe just follow what Linux suggested: pass vma to pte_dirty() and always return false for these special VMAs.
On 11.07.24 19:57, Linus Torvalds wrote: > On Thu, 11 Jul 2024 at 10:09, Jason A. Donenfeld <Jason@zx2c4.com> wrote: >> >> When I was working on this patchset this year with the syscall, this is >> similar somewhat to the initial approach I was taking with setting up a >> special mapping. It turned into kind of a mess and I couldn't get it >> working. There's a lot of functionality built around anonymous pages >> that would need to be duplicated (I think?). > > Yeah, I was kind of assuming that. You'd need to handle VM_DROPPABLE > in the fault path specially, the way we currently split up based on > vma_is_anonymous(), eg > > if (vma_is_anonymous(vmf->vma)) > return do_anonymous_page(vmf); > else > return do_fault(vmf); > > in do_pte_missing() etc. > > I don't actually think it would be too hard, but it's a more > "conceptual" change, and it's probably not worth it. > >> Alright, an hour later of fiddling, and it doesn't actually work (yet?) >> -- the selftest fails. A diff follows below. > > May I suggest a slightly different approach: do what we did for "pte_mkwrite()". > > It needed the vma too, for not too dissimilar reasons: special dirty > bit handling for the shadow stack. See > > bb3aadf7d446 ("x86/mm: Start actually marking _PAGE_SAVED_DIRTY") > b497e52ddb2a ("x86/mm: Teach pte_mkwrite() about stack memory") > > and now we have "pte_mkwrite_novma()" with the old semantics for the > legacy cases that didn't get converted - whether it's because the > architecture doesn't have the issue, or because it's a kernel pte. > > And the conversion was actually quite pain-free, because we have > > #ifndef pte_mkwrite > static inline pte_t pte_mkwrite(pte_t pte, struct vm_area_struct *vma) > { > return pte_mkwrite_novma(pte); > } > #endif > > so all any architecture that didn't want this needed to do was to > rename their pte_mkwrite() to pte_mkwrite_novma() and they were done. > In fact, that was done first as basically semantically no-op patches: > > 2f0584f3f4bd ("mm: Rename arch pte_mkwrite()'s to pte_mkwrite_novma()") > 6ecc21bb432d ("mm: Move pte/pmd_mkwrite() callers with no VMA to _novma()") > 161e393c0f63 ("mm: Make pte_mkwrite() take a VMA") > > which made this all very pain-free (and was largely a sed script, I think). > >> - !pte_dirty(pte) && !PageDirty(page)) >> + !pte_dirty(pte) && !PageDirty(page) && >> + !(vma->vm_flags & VM_DROPPABLE)) > > So instead of this kind of thing, we'd have > >> - !pte_dirty(pte) && !PageDirty(page)) >> + !pte_dirty(pte, vma) && !PageDirty(page) && > > and the advantage here is that you can't miss anybody by mistake. The > compiler will be very unhappy if you don't pass in the vma, and then > any places that would be converted to "pte_dirty_novma()" > > We don't actually have all that many users of pte_dirty(), so it > doesn't look too nasty. And if we make the pte_dirty() semantics > depend on the vma, I really think we should do it the same way we did > pte_mkwrite(). We also have these folio_mark_dirty() calls, for example in unpin_user_pages_dirty_lock(). Hm ... so preventing the folio from getting dirtied is likely shaky. I guess we need a way to just reliably identify these folios :/.
On Thu, 11 Jul 2024 at 12:08, David Hildenbrand <david@redhat.com> wrote: > > We also have these folio_mark_dirty() calls, for example in > unpin_user_pages_dirty_lock(). Hm ... so preventing the folio from > getting dirtied is likely shaky. I do wonder if we should just disallow page pinning for these pages entirely. When the page can get replaced by zeroes at any time, pinning it doesn't make much sense. Except we do have that whole "fast" case that intentionally doesn't take locks and doesn't have a vma. Darn. Linus
On 11.07.24 21:18, David Hildenbrand wrote: > On 11.07.24 20:56, David Hildenbrand wrote: >> On 11.07.24 20:54, Jason A. Donenfeld wrote: >>> On Thu, Jul 11, 2024 at 08:24:07PM +0200, David Hildenbrand wrote: >>>>> And PG_large_rmappable seems to only be used for hugetlb branches. >>>> >>>> It should be set for THP/large folios. >>> >>> And it's tested too, apparently. >>> >>> Okay, well, how disappointing is this below? Because I'm running out of >>> tricks for flag reuse. >>> >>> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h >>> index b9e914e1face..c1ea49a7f198 100644 >>> --- a/include/linux/page-flags.h >>> +++ b/include/linux/page-flags.h >>> @@ -110,6 +110,7 @@ enum pageflags { >>> PG_workingset, >>> PG_error, >>> PG_owner_priv_1, /* Owner use. If pagecache, fs may use*/ >>> + PG_owner_priv_2, >> >> Oh no, no new page flags please :) >> >> Maybe just follow what Linux suggested: pass vma to pte_dirty() and >> always return false for these special VMAs. > > ... or look into removing that one case that gives us headake. > > No idea what would happen if we do the following: > > CCing Yu Zhao. > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 0761f91b407f..d1dfbd4fd38d 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -4280,14 +4280,9 @@ static bool sort_folio(struct lruvec *lruvec, struct folio *folio, struct scan_c > return true; > } > > - /* dirty lazyfree */ > - if (type == LRU_GEN_FILE && folio_test_anon(folio) && folio_test_dirty(folio)) { > - success = lru_gen_del_folio(lruvec, folio, true); > - VM_WARN_ON_ONCE_FOLIO(!success, folio); > - folio_set_swapbacked(folio); > - lruvec_add_folio_tail(lruvec, folio); > - return true; > - } > + /* lazyfree: we may not be allowed to set swapbacked: MAP_DROPPABLE */ > + if (type == LRU_GEN_FILE && folio_test_anon(folio) && folio_test_dirty(folio)) > + return false; Note that something is unclear to me: are we maybe running into that code also if folio_set_swapbacked() is already set and we are not in the lazyfree path (in contrast to what is documented)?
On 11.07.24 21:17, Linus Torvalds wrote: > On Thu, 11 Jul 2024 at 12:08, David Hildenbrand <david@redhat.com> wrote: >> >> We also have these folio_mark_dirty() calls, for example in >> unpin_user_pages_dirty_lock(). Hm ... so preventing the folio from >> getting dirtied is likely shaky. > > I do wonder if we should just disallow page pinning for these pages > entirely. When the page can get replaced by zeroes at any time, > pinning it doesn't make much sense. > > Except we do have that whole "fast" case that intentionally doesn't > take locks and doesn't have a vma. Darn. Yeah, and I think it should all be simpler; we shouldn't have to special-case these cases everywhere. Maybe we can just find a way to not do *folio_set_swapbacked() without a VMA.
On Thu, Jul 11, 2024 at 1:20 PM David Hildenbrand <david@redhat.com> wrote: > > On 11.07.24 21:18, David Hildenbrand wrote: > > On 11.07.24 20:56, David Hildenbrand wrote: > >> On 11.07.24 20:54, Jason A. Donenfeld wrote: > >>> On Thu, Jul 11, 2024 at 08:24:07PM +0200, David Hildenbrand wrote: > >>>>> And PG_large_rmappable seems to only be used for hugetlb branches. > >>>> > >>>> It should be set for THP/large folios. > >>> > >>> And it's tested too, apparently. > >>> > >>> Okay, well, how disappointing is this below? Because I'm running out of > >>> tricks for flag reuse. > >>> > >>> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h > >>> index b9e914e1face..c1ea49a7f198 100644 > >>> --- a/include/linux/page-flags.h > >>> +++ b/include/linux/page-flags.h > >>> @@ -110,6 +110,7 @@ enum pageflags { > >>> PG_workingset, > >>> PG_error, > >>> PG_owner_priv_1, /* Owner use. If pagecache, fs may use*/ > >>> + PG_owner_priv_2, > >> > >> Oh no, no new page flags please :) > >> > >> Maybe just follow what Linux suggested: pass vma to pte_dirty() and > >> always return false for these special VMAs. > > > > ... or look into removing that one case that gives us headake. > > > > No idea what would happen if we do the following: > > > > CCing Yu Zhao. > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 0761f91b407f..d1dfbd4fd38d 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -4280,14 +4280,9 @@ static bool sort_folio(struct lruvec *lruvec, struct folio *folio, struct scan_c > > return true; > > } > > > > - /* dirty lazyfree */ > > - if (type == LRU_GEN_FILE && folio_test_anon(folio) && folio_test_dirty(folio)) { > > - success = lru_gen_del_folio(lruvec, folio, true); > > - VM_WARN_ON_ONCE_FOLIO(!success, folio); > > - folio_set_swapbacked(folio); > > - lruvec_add_folio_tail(lruvec, folio); > > - return true; > > - } > > + /* lazyfree: we may not be allowed to set swapbacked: MAP_DROPPABLE */ > > + if (type == LRU_GEN_FILE && folio_test_anon(folio) && folio_test_dirty(folio)) > > + return false; This is an optimization to avoid an unnecessary trip to shrink_folio_list(), so it's safe to delete the entire 'if' block, and that would be preferable than leaving a dangling 'if'. > Note that something is unclear to me: are we maybe running into that > code also if folio_set_swapbacked() is already set and we are not in the > lazyfree path (in contrast to what is documented)? Not sure what you mean: either rmap sees pte_dirty() and does folio_mark_dirty() and then folio_set_swapbacked(); or MGLRU does the same sequence, with the first two steps in walk_pte_range() and the last one here.
On 11.07.24 21:49, Yu Zhao wrote: > On Thu, Jul 11, 2024 at 1:20 PM David Hildenbrand <david@redhat.com> wrote: >> >> On 11.07.24 21:18, David Hildenbrand wrote: >>> On 11.07.24 20:56, David Hildenbrand wrote: >>>> On 11.07.24 20:54, Jason A. Donenfeld wrote: >>>>> On Thu, Jul 11, 2024 at 08:24:07PM +0200, David Hildenbrand wrote: >>>>>>> And PG_large_rmappable seems to only be used for hugetlb branches. >>>>>> >>>>>> It should be set for THP/large folios. >>>>> >>>>> And it's tested too, apparently. >>>>> >>>>> Okay, well, how disappointing is this below? Because I'm running out of >>>>> tricks for flag reuse. >>>>> >>>>> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h >>>>> index b9e914e1face..c1ea49a7f198 100644 >>>>> --- a/include/linux/page-flags.h >>>>> +++ b/include/linux/page-flags.h >>>>> @@ -110,6 +110,7 @@ enum pageflags { >>>>> PG_workingset, >>>>> PG_error, >>>>> PG_owner_priv_1, /* Owner use. If pagecache, fs may use*/ >>>>> + PG_owner_priv_2, >>>> >>>> Oh no, no new page flags please :) >>>> >>>> Maybe just follow what Linux suggested: pass vma to pte_dirty() and >>>> always return false for these special VMAs. >>> >>> ... or look into removing that one case that gives us headake. >>> >>> No idea what would happen if we do the following: >>> >>> CCing Yu Zhao. >>> >>> diff --git a/mm/vmscan.c b/mm/vmscan.c >>> index 0761f91b407f..d1dfbd4fd38d 100644 >>> --- a/mm/vmscan.c >>> +++ b/mm/vmscan.c >>> @@ -4280,14 +4280,9 @@ static bool sort_folio(struct lruvec *lruvec, struct folio *folio, struct scan_c >>> return true; >>> } >>> >>> - /* dirty lazyfree */ >>> - if (type == LRU_GEN_FILE && folio_test_anon(folio) && folio_test_dirty(folio)) { >>> - success = lru_gen_del_folio(lruvec, folio, true); >>> - VM_WARN_ON_ONCE_FOLIO(!success, folio); >>> - folio_set_swapbacked(folio); >>> - lruvec_add_folio_tail(lruvec, folio); >>> - return true; >>> - } >>> + /* lazyfree: we may not be allowed to set swapbacked: MAP_DROPPABLE */ >>> + if (type == LRU_GEN_FILE && folio_test_anon(folio) && folio_test_dirty(folio)) >>> + return false; > > This is an optimization to avoid an unnecessary trip to > shrink_folio_list(), so it's safe to delete the entire 'if' block, and > that would be preferable than leaving a dangling 'if'. Great, thanks. > >> Note that something is unclear to me: are we maybe running into that >> code also if folio_set_swapbacked() is already set and we are not in the >> lazyfree path (in contrast to what is documented)? > > Not sure what you mean: either rmap sees pte_dirty() and does > folio_mark_dirty() and then folio_set_swapbacked(); or MGLRU does the > same sequence, with the first two steps in walk_pte_range() and the > last one here. Let me rephrase: Checking for lazyfree is "folio_test_anon(folio) && !folio_test_swapbacked(folio)" Testing for dirtied lazyfree is "folio_test_anon(folio) && !folio_test_swapbacked(folio) && folio_test)dirty(folio)" So I'm wondering about the missing folio_test_swapbacked() test.
Hi Linus, On Thu, Jul 11, 2024 at 10:57:17AM -0700, Linus Torvalds wrote: > May I suggest a slightly different approach: do what we did for "pte_mkwrite()". > > It needed the vma too, for not too dissimilar reasons: special dirty > bit handling for the shadow stack. See Thanks for the suggestion. That seems pretty clean. It still needs to avoid setting swapbacked in the first place, but ensuring that it's never dirty means it won't get turned back on. The first patch renames pte_dirty() to pte_dirty_novma(). The second patch adds an inline function, pte_dirty(pte, vma) that just forwards the pte to pte_dirty_novma(), and then converts callers that have a vma available to pass to call pte_dirty(). And then the VM_DROPPABLE patch simply adds the `&& !(vma->vm_flags & VM_DROPPABLE)` condition to pte_dirty(). I put these in https://git.zx2c4.com/linux-rng/log/ per usual, and I'll post a new version to the list not before long (unless objections). Jason
On Thu, Jul 11, 2024 at 10:07:30PM +0200, Jason A. Donenfeld wrote: > Hi Linus, > > On Thu, Jul 11, 2024 at 10:57:17AM -0700, Linus Torvalds wrote: > > May I suggest a slightly different approach: do what we did for "pte_mkwrite()". > > > > It needed the vma too, for not too dissimilar reasons: special dirty > > bit handling for the shadow stack. See > > Thanks for the suggestion. That seems pretty clean. > > It still needs to avoid setting swapbacked in the first place, but > ensuring that it's never dirty means it won't get turned back on. > > The first patch renames pte_dirty() to pte_dirty_novma(). The second > patch adds an inline function, pte_dirty(pte, vma) that just forwards > the pte to pte_dirty_novma(), and then converts callers that have a vma > available to pass to call pte_dirty(). And then the VM_DROPPABLE patch > simply adds the `&& !(vma->vm_flags & VM_DROPPABLE)` condition to > pte_dirty(). > > I put these in https://git.zx2c4.com/linux-rng/log/ per usual, and I'll > post a new version to the list not before long (unless objections). Oh, I didn't catch upthread in time (my mail flow is based on `lei up`, which I guess I should run at greater frequency). It seems like we apparently might go in a different direction. I'll move that to https://git.zx2c4.com/linux-rng/log/?h=jd/pte_dirty in case it's useful later, though. Jason
Hi David, On Thu, Jul 11, 2024 at 01:49:42PM -0600, Yu Zhao wrote: > On Thu, Jul 11, 2024 at 1:20 PM David Hildenbrand <david@redhat.com> wrote: > > > - /* dirty lazyfree */ > > > - if (type == LRU_GEN_FILE && folio_test_anon(folio) && folio_test_dirty(folio)) { > > > - success = lru_gen_del_folio(lruvec, folio, true); > > > - VM_WARN_ON_ONCE_FOLIO(!success, folio); > > > - folio_set_swapbacked(folio); > > > - lruvec_add_folio_tail(lruvec, folio); > > > - return true; > > > - } > This is an optimization to avoid an unnecessary trip to > shrink_folio_list(), so it's safe to delete the entire 'if' block, and > that would be preferable than leaving a dangling 'if'. Alright, I'll just remove that entire chunk then, for v+1 of this patch? That sounds prettttty okay. Jason
On 11.07.24 22:20, Jason A. Donenfeld wrote: > Hi David, > > On Thu, Jul 11, 2024 at 01:49:42PM -0600, Yu Zhao wrote: >> On Thu, Jul 11, 2024 at 1:20 PM David Hildenbrand <david@redhat.com> wrote: >>>> - /* dirty lazyfree */ >>>> - if (type == LRU_GEN_FILE && folio_test_anon(folio) && folio_test_dirty(folio)) { >>>> - success = lru_gen_del_folio(lruvec, folio, true); >>>> - VM_WARN_ON_ONCE_FOLIO(!success, folio); >>>> - folio_set_swapbacked(folio); >>>> - lruvec_add_folio_tail(lruvec, folio); >>>> - return true; >>>> - } > >> This is an optimization to avoid an unnecessary trip to >> shrink_folio_list(), so it's safe to delete the entire 'if' block, and >> that would be preferable than leaving a dangling 'if'. > > Alright, I'll just remove that entire chunk then, for v+1 of this patch? > That sounds prettttty okay. Yes!
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().
On Fri, Jul 12, 2024 at 12:29:17AM +0200, David Hildenbrand wrote: > > 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: Thank you for coming up with them! > We don't want to suddenly get pages that are swapbacked. > Otherwise someone could place swapbacked pages in there (using UFFDIO_MOVE) Both seem like reasonable concerns. Added to v+1. Jason
The plan for this series is to take it through my random.git tree for 6.11. It's cooking in linux-next now. Changes v21->v22: - Only add MAP_DROPPABLE, not the other MAP_*s, but make it imply the other relevant flags. - Ensure that mlock() and madvise() can't undo MAP_DROPPABLE implications. - Since MAP_DROPPABLE is generally useful, remove conditional Kconfig scafolding around it. - Follow mm/ standards on comment style. - Base atop latest selftest PR, to avoid merge conflicts in 6.11. - Update glibc patches. Changes v20->v21: - After extensive conversation with Linus, we're nixing the entire vgetrandom_alloc() syscall, in favor of just exposing the functionality needed through mmap() and having the kernel communicate to the caller what arguments/sizes it should pass to mmap(). This simplifies the series considerably. It also means that the first commit adds some new MAP_* constants for mmap(). - Separate vDSO selftests out into separate commit. -------------- Useful links: - This series: - https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/log/ - Glibc patches by Adhemerval and me against glibc-2.39: - https://git.zx2c4.com/glibc/log/?h=vdso - In case you're actually interested in the v≤14 design where faults were non-fatal and instructions were skipped (which I think is more coherent, even if the implementation is controversial), this lives in my branch here: - https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/log/?h=jd/vdso-skip-insn Note that I'm *not* actually proposing this for upstream at this time. But it may be of conversational interest. ------------- Two statements: 1) Userspace wants faster cryptographically secure random numbers of arbitrary size, big or small. 2) Userspace is currently unable to safely roll its own RNG with the same security profile as getrandom(). Statement (1) has been debated for years, with arguments ranging from "we need faster cryptographically secure card shuffling!" to "the only things that actually need good randomness are keys, which are few and far between" to "actually, TLS CBC nonces are frequent" and so on. I don't intend to wade into that debate substantially, except to note that recently glibc added arc4random(), whose goal is to return a cryptographically secure uint32_t, and there are real user reports of it being too slow. So here we are. Statement (2) is more interesting. The kernel is the nexus of all entropic inputs that influence the RNG. It is in the best position, and probably the only position, to decide anything at all about the current state of the RNG and of its entropy. One of the things it uniquely knows about is when reseeding is necessary. For example, when a virtual machine is forked, restored, or duplicated, it's imparative that the RNG doesn't generate the same outputs. For this reason, there's a small protocol between hypervisors and the kernel that indicates this has happened, alongside some ID, which the RNG uses to immediately reseed, so as not to return the same numbers. Were userspace to expand a getrandom() seed from time T1 for the next hour, and at some point T2 < hour, the virtual machine forked, userspace would continue to provide the same numbers to two (or more) different virtual machines, resulting in potential cryptographic catastrophe. Something similar happens on resuming from hibernation (or even suspend), with various compromise scenarios there in mind. There's a more general reason why userspace rolling its own RNG from a getrandom() seed is fraught. There's a lot of attention paid to this particular Linuxism we have of the RNG being initialized and thus non-blocking or uninitialized and thus blocking until it is initialized. These are our Two Big States that many hold to be the holy differentiating factor between safe and not safe, between cryptographically secure and garbage. The fact is, however, that the distinction between these two states is a hand-wavy wishy-washy inexact approximation. Outside of a few exceptional cases (e.g. a HW RNG is available), we actually don't really ever know with any rigor at all when the RNG is safe and ready (nor when it's compromised). We do the best we can to "estimate" it, but entropy estimation is fundamentally impossible in the general case. So really, we're just doing guess work, and hoping it's good and conservative enough. Let's then assume that there's always some potential error involved in this differentiator. In fact, under the surface, the RNG is engineered around a different principle, and that is trying to *use* new entropic inputs regularly and at the right specific moments in time. For example, close to boot time, the RNG reseeds itself more often than later. At certain events, like VM fork, the RNG reseeds itself immediately. The various heuristics for when the RNG will use new entropy and how often is really a core aspect of what the RNG has some potential to do decently enough (and something that will probably continue to improve in the future from random.c's present set of algorithms). So in your mind, put away the metal attachment to the Two Big States, which represent an approximation with a potential margin of error. Instead keep in mind that the RNG's primary operating heuristic is how often and exactly when it's going to reseed. So, if userspace takes a seed from getrandom() at point T1, and uses it for the next hour (or N megabytes or some other meaningless metric), during that time, potential errors in the Two Big States approximation are amplified. During that time potential reseeds are being lost, forgotten, not reflected in the output stream. That's not good. The simplest statement you could make is that userspace RNGs that expand a getrandom() seed at some point T1 are nearly always *worse*, in some way, than just calling getrandom() every time a random number is desired. For those reasons, after some discussion on libc-alpha, glibc's arc4random() now just calls getrandom() on each invocation. That's trivially safe, and gives us latitude to then make the safe thing faster without becoming unsafe at our leasure. Card shuffling isn't particularly fast, however. How do we rectify this? By putting a safe implementation of getrandom() in the vDSO, which has access to whatever information a particular iteration of random.c is using to make its decisions. I use that careful language of "particular iteration of random.c", because the set of things that a vDSO getrandom() implementation might need for making decisions as good as the kernel's will likely change over time. This isn't just a matter of exporting certain *data* to userspace. We're not going to commit to a "data API" where the various heuristics used are exposed, locking in how the kernel works for decades to come, and then leave it to various userspaces to roll something on top and shoot themselves in the foot and have all sorts of complexity disasters. Rather, vDSO getrandom() is supposed to be the *same exact algorithm* that runs in the kernel, except it's been hoisted into userspace as much as possible. And so vDSO getrandom() and kernel getrandom() will always mirror each other hermetically. API-wise, the vDSO gains this function: ssize_t vgetrandom(void *buffer, size_t len, unsigned int flags, void *opaque_state, size_t opaque_len); The return value and the first 3 arguments are the same as ordinary getrandom(), while the penultimate argument is a pointer to some state allocated with the right flags passed to mmap(2), explained below. Were all five arguments passed to the getrandom syscall, nothing different would happen, and the functions would have the exact same behavior. If vgetrandom(NULL, 0, 0, ¶ms, ~0UL) is called, then params gets populated with information about what flags and prot fields to pass to mmap(2), as well as how big each state should be, so that the caller can slice up returned memory from mmap(2) into chunks for passing to vgetrandom(). Libc is expected to allocate a chunk of these on first use, and then dole them out to threads as they're created, allocating more when needed. The interesting meat of the implementation is in lib/vdso/getrandom.c, as generic C code, and it aims to mainly follow random.c's buffered fast key erasure logic. Before the RNG is initialized, it falls back to the syscall. Right now it uses a simple generation counter to make its decisions on reseeding (though this could be made more extensive over time). The actual place that has the most work to do is in all of the other files. Most of the vDSO shared page infrastructure is centered around gettimeofday, and so the main structs are all in arrays for different timestamp types, and attached to time namespaces, and so forth. I've done the best I could to add onto this in an unintrusive way. In my test results, performance is pretty stellar (around 15x for uint32_t generation), and it seems to be working. There's an extended example in the last commit of this series, showing how the syscall and the vDSO function are meant to be used together. Cc: linux-crypto@vger.kernel.org Cc: linux-api@vger.kernel.org Cc: x86@kernel.org Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> Cc: Carlos O'Donell <carlos@redhat.com> Cc: Florian Weimer <fweimer@redhat.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Jann Horn <jannh@google.com> Cc: Christian Brauner <brauner@kernel.org> Cc: David Hildenbrand <dhildenb@redhat.com> Jason A. Donenfeld (4): mm: add MAP_DROPPABLE for designating always lazily freeable mappings random: introduce generic vDSO getrandom() implementation x86: vdso: Wire up getrandom() vDSO implementation selftests/vDSO: add tests for vgetrandom MAINTAINERS | 4 + arch/x86/Kconfig | 1 + arch/x86/entry/vdso/Makefile | 3 +- arch/x86/entry/vdso/vdso.lds.S | 2 + arch/x86/entry/vdso/vgetrandom-chacha.S | 178 +++++++++++ arch/x86/entry/vdso/vgetrandom.c | 17 ++ arch/x86/include/asm/vdso/getrandom.h | 55 ++++ arch/x86/include/asm/vdso/vsyscall.h | 2 + arch/x86/include/asm/vvar.h | 16 + drivers/char/random.c | 18 +- fs/proc/task_mmu.c | 1 + include/linux/mm.h | 7 + include/trace/events/mmflags.h | 7 + include/uapi/linux/mman.h | 1 + include/uapi/linux/random.h | 15 + include/vdso/datapage.h | 11 + include/vdso/getrandom.h | 46 +++ lib/vdso/Kconfig | 5 + lib/vdso/getrandom.c | 251 +++++++++++++++ mm/madvise.c | 5 +- mm/mlock.c | 2 +- mm/mmap.c | 30 ++ mm/rmap.c | 22 +- tools/include/asm/rwonce.h | 0 tools/include/uapi/linux/mman.h | 1 + tools/testing/selftests/mm/.gitignore | 1 + tools/testing/selftests/mm/Makefile | 1 + tools/testing/selftests/mm/droppable.c | 53 ++++ tools/testing/selftests/vDSO/.gitignore | 2 + tools/testing/selftests/vDSO/Makefile | 18 ++ .../testing/selftests/vDSO/vdso_test_chacha.c | 43 +++ .../selftests/vDSO/vdso_test_getrandom.c | 288 ++++++++++++++++++ 32 files changed, 1099 insertions(+), 7 deletions(-) create mode 100644 arch/x86/entry/vdso/vgetrandom-chacha.S create mode 100644 arch/x86/entry/vdso/vgetrandom.c create mode 100644 arch/x86/include/asm/vdso/getrandom.h create mode 100644 include/vdso/getrandom.h create mode 100644 lib/vdso/getrandom.c create mode 100644 tools/include/asm/rwonce.h create mode 100644 tools/testing/selftests/mm/droppable.c create mode 100644 tools/testing/selftests/vDSO/vdso_test_chacha.c create mode 100644 tools/testing/selftests/vDSO/vdso_test_getrandom.c base-commit: 22a40d14b572deb80c0648557f4bd502d7e83826 prerequisite-patch-id: 9a45c4b77033012b2c2cbbec24fd8b2a7a5daf84 prerequisite-patch-id: 8b773921433de1e8b9fd5a8f3d6107258c133c2a prerequisite-patch-id: afd1b07bd24fe3c93d1fef782ba9064e95d1534c prerequisite-patch-id: a5cbcafe6072a173a8f20eac5cc7e545be50ae20 prerequisite-patch-id: 59640753e9c60e5d23ede9a20ed5c933a47b3f97