Michael Ellerman <mpe@xxxxxxxxxxxxxx> writes: > "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxx> writes: > >> Architectures like ppc64 require to do a conditional tlb flush based on the old >> and new value of pte. Enable that by passing old pte value as the arg. > > It's not actually the architecture, it's to work around a specific bug > on Power9. > >> diff --git a/mm/mprotect.c b/mm/mprotect.c >> index c89ce07923c8..028c724dcb1a 100644 >> --- a/mm/mprotect.c >> +++ b/mm/mprotect.c >> @@ -110,8 +110,8 @@ static unsigned long change_pte_range(struct vm_area_struct *vma, pmd_t *pmd, >> continue; >> } >> >> - ptent = ptep_modify_prot_start(vma, addr, pte); >> - ptent = pte_modify(ptent, newprot); >> + oldpte = ptep_modify_prot_start(vma, addr, pte); >> + ptent = pte_modify(oldpte, newprot); >> if (preserve_write) >> ptent = pte_mk_savedwrite(ptent); > > Is it OK to reuse oldpte here? > > It was set at the top of the loop with: > > oldpte = *pte; > > Is it guaranteed that ptep_modify_prot_start() returns the old value > unmodified, or could an implementation conceivably filter some bits out? > > If so then it could be confusing for oldpte to have its value change > half way through the loop. > ptep_modify_prot_start and ptep_modify_prot_commit is the sequence that we can safely use to do read/modify/update of a pte entry. Now w.r.t old pte, we can't update the pte bits from software because we are holding the page table lock(ptl). Now we could definitely end up having updated reference and change bit. But we make sure we don't lose those by using prot_start and prot_commit sequence. -aneesh
