Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] mm: missing TLB flush on hmm_vma_handle_pte error path during migration --
commit cabe68b53951d20b6fe5d611bd88bef73ab4ed62 Author: Mika Penttilä <[email protected]> mm/hmm: add lazy MMU mode support for migration in HMM pagewalk This commit adds calls to lazy_mmu_mode_enable() and lazy_mmu_mode_disable() while performing migration in the HMM pagewalk paths. > diff --git a/mm/hmm.c b/mm/hmm.c > index a1459bd34c04e..a67a23e545512 100644 > --- a/mm/hmm.c > +++ b/mm/hmm.c [ ... ] > @@ -1178,6 +1184,7 @@ static int hmm_vma_walk_pmd(pmd_t *pmdp, > flush_tlb_range(walk->vma, start, addr); [Severity: High] Does this skip a necessary TLB flush on the error path during migration? If hmm_range_fault() with migration enabled successfully unmaps a page in the loop of hmm_vma_walk_pmd(), and then in the next loop iteration (for the same PMD), hmm_vma_handle_pte() encounters a page requiring a fault, it drops the PTE lock and returns an error: hmm_vma_walk_pmd() { ... for (; addr < end; addr += PAGE_SIZE, ptep++, hmm_pfns++) { r = hmm_vma_handle_pte(walk, addr, end, pmdp, ptep, hmm_pfns); if (r) { /* hmm_vma_handle_pte() did pte_unmap() / pte_unmap_unlock */ return r; } ... } Because the loop terminates with an immediate return, it completely bypasses the flush_tlb_range() check shown below. Could this leave stale TLB entries mapping old physical pages despite the page tables pointing to migration entries, potentially causing data corruption if writes to the old page are lost? > > if (hmm_vma_walk->ptelocked) { > + lazy_mmu_mode_disable(); > pte_unmap_unlock(ptep - 1, hmm_vma_walk->ptl); > hmm_vma_walk->ptelocked = false; > } else { -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=8
