lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 30 Oct 2022 18:44:10 -0700 From: Mike Kravetz <mike.kravetz@...cle.com> To: Nadav Amit <nadav.amit@...il.com> Cc: Peter Xu <peterx@...hat.com>, Linux-MM <linux-mm@...ck.org>, kernel list <linux-kernel@...r.kernel.org>, Naoya Horiguchi <naoya.horiguchi@...ux.dev>, David Hildenbrand <david@...hat.com>, Axel Rasmussen <axelrasmussen@...gle.com>, Mina Almasry <almasrymina@...gle.com>, Rik van Riel <riel@...riel.com>, Vlastimil Babka <vbabka@...e.cz>, Matthew Wilcox <willy@...radead.org>, Andrew Morton <akpm@...ux-foundation.org>, Wei Chen <harperchen1110@...il.com>, "# 5 . 10+" <stable@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org> Subject: Re: [PATCH v2] hugetlb: don't delete vma_lock in hugetlb MADV_DONTNEED processing On 10/30/22 11:52, Nadav Amit wrote: > On Oct 30, 2022, at 11:43 AM, Peter Xu <peterx@...hat.com> wrote: > > > The loop comes from 7e027b14d53e ("vm: simplify unmap_vmas() calling > > convention", 2012-05-06), where zap_page_range() was used to replace a call > > to unmap_vmas() because the patch wanted to eliminate the zap details > > pointer for unmap_vmas(), which makes sense. > > > > I didn't check the old code, but from what I can tell (and also as Mike > > pointed out) I don't think zap_page_range() in the lastest code base is > > ever used on multi-vma at all. Otherwise the mmu notifier is already > > broken - see mmu_notifier_range_init() where the vma pointer is also part > > of the notification. > > > > Perhaps we should just remove the loop? > > There is already zap_page_range_single() that does exactly that. Just need > to export it. I was thinking that zap_page_range() should perform a notification call for each vma within the loop. Something like this? @@ -1704,15 +1704,21 @@ void zap_page_range(struct vm_area_struct *vma, unsigned long start, MA_STATE(mas, mt, vma->vm_end, vma->vm_end); lru_add_drain(); - mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm, - start, start + size); tlb_gather_mmu(&tlb, vma->vm_mm); update_hiwater_rss(vma->vm_mm); - mmu_notifier_invalidate_range_start(&range); do { - unmap_single_vma(&tlb, vma, start, range.end, NULL); + mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, + vma->vm_mm, + max(start, vma->vm_start), + min(start + size, vma->vm_end)); + if (is_vm_hugetlb_page(vma)) + adjust_range_if_pmd_sharing_possible(vma, + &range.start, + &range.end); + mmu_notifier_invalidate_range_start(&range); + unmap_single_vma(&tlb, vma, start, start + size, NULL); + mmu_notifier_invalidate_range_end(&range); } while ((vma = mas_find(&mas, end - 1)) != NULL); - mmu_notifier_invalidate_range_end(&range); tlb_finish_mmu(&tlb); } One thing to keep in mind is that this patch is a fix that must be backported to stable. Therefore, I do not think we want to add too many changes out of the direct scope of the fix. We can always change things like this in follow up patches. -- Mike Kravetz
Powered by blists - more mailing lists