On 11/30/22 10:58, Peter Xu wrote: > Hi, Mike, > > On Tue, Nov 29, 2022 at 08:55:21PM -0800, Mike Kravetz wrote: > > > + * (2) For shared mappings: pmd unsharing is possible (so the PUD-ranged > > > + * pgtable page can go away from under us! It can be done by a pmd > > > + * unshare with a follow up munmap() on the other process), then we > > > + * need either: > > > + * > > > + * (2.1) hugetlb vma lock read or write held, to make sure pmd unshare > > > + * won't happen upon the range (it also makes sure the pte_t we > > > + * read is the right and stable one), or, > > > + * > > > + * (2.2) hugetlb mapping i_mmap_rwsem lock held read or write, to make > > > + * sure even if unshare happened the racy unmap() will wait until > > > + * i_mmap_rwsem is released. > > > > Is that 100% correct? IIUC, the page tables will be released via the > > call to tlb_finish_mmu(). In most cases, the tlb_finish_mmu() call is > > performed when holding i_mmap_rwsem. However, in the final teardown of > > a hugetlb vma via __unmap_hugepage_range_final, the tlb_finish_mmu call > > is done outside the i_mmap_rwsem lock. In this case, I think we are > > still safe because nobody else should be walking the page table. > > > > I really like the documentation. However, if i_mmap_rwsem is not 100% > > safe I would prefer not to document it here. I don't think anyone > > relies on this do they? > > I think i_mmap_rwsem is 100% safe. > > It's not in tlb_finish_mmu(), but when freeing the pgtables we need to > unlink current vma from the vma list first: > > free_pgtables > unlink_file_vma > i_mmap_lock_write > tlb_finish_mmu Thanks! Sorry, I was thinking about page freeing not page table freeing. Agree that is 100% safe. -- Mike Kravetz
