On Thu, Apr 4, 2024 at 1:16 PM David Hildenbrand <david@xxxxxxxxxx> wrote: > > On 04.04.24 22:07, Suren Baghdasaryan wrote: > > On Thu, Apr 4, 2024 at 10:21 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > >> > >> On Thu, Apr 04, 2024 at 10:17:26AM -0700, Lokesh Gidra wrote: > >>> - folio_move_anon_rmap(src_folio, dst_vma); > >>> - WRITE_ONCE(src_folio->index, linear_page_index(dst_vma, dst_addr)); > >>> - > >>> src_pmdval = pmdp_huge_clear_flush(src_vma, src_addr, src_pmd); > >>> /* Folio got pinned from under us. Put it back and fail the move. */ > >>> if (folio_maybe_dma_pinned(src_folio)) { > >>> @@ -2270,6 +2267,9 @@ int move_pages_huge_pmd(struct mm_struct *mm, pmd_t *dst_pmd, pmd_t *src_pmd, pm > >>> goto unlock_ptls; > >>> } > >>> > >>> + folio_move_anon_rmap(src_folio, dst_vma); > >>> + WRITE_ONCE(src_folio->index, linear_page_index(dst_vma, dst_addr)); > >>> + > >> > >> This use of WRITE_ONCE scares me. We hold the folio locked. Why do > >> we need to use WRITE_ONCE? Who's looking at folio->index without > >> holding the folio lock? > > > > Indeed that seems to be unnecessary here. Both here and in > > move_present_pte() we are holding folio lock while moving the page. I > > must have just blindly copied that from Andrea's original patch [1]. > > Agreed, I don't think it is required for ->index. (I also don't spot any > corresponding READ_ONCE) Since this patch just got Ack'ed, I'll wait for Andrew to take it into mm-unstable and then will send a fix removing those WRITE_ONCE(). That way we won't have merge conflicts, > > -- > Cheers, > > David / dhildenb >