Re: [PATCH v2 28/40] mm/memory: page_remove_rmap() -> folio_remove_rmap_pte()

[David Hildenbrand]

On 22.01.24 18:34, David Hildenbrand wrote:
> On 22.01.24 18:20, Matthew Wilcox wrote:
> > On Mon, Jan 22, 2024 at 06:01:58PM +0100, David Hildenbrand wrote:
> > > > And folio_mark_dirty() is doing more than just setting teh PG_dirty bit. In my
> > > > equivalent change, as part of the contpte series, I've swapped set_page_dirty()
> > > > for folio_mark_dirty().
> > >
> > > Good catch, that should be folio_mark_dirty(). Let me send a fixup.
> > >
> > > (the difference in naming for both functions really is bad)
> >
> > It really is, and I don't know what to do about it.
> >
> > We need a function that literally just sets the flag.  For every other
> > flag, that's folio_set_FLAG.  We can't use __folio_set_flag because that
> > means "set the flag non-atomically".
> >
> > We need a function that does all of the work involved with tracking
> > dirty folios.  I chose folio_mark_dirty() to align with
> > folio_mark_uptodate() (ie mark is not just 'set" but also "do some extra
> > work").
> >
> > But because we're converting from set_page_dirty(), the OBVIOUS rename
> > is to folio_set_dirty(), which is WRONG.
>
> And I made the same mistake at least also in "mm/huge_memory:
> page_remove_rmap() -> folio_remove_rmap_pmd()".
>
> I better double check all these so-simple-looking conversions that just
> went upstream.
>
> Interestingly, __split_huge_pmd_locked() used SetPageReferenced()
> instead of

Forgot to delete that sentence.

Anyhow, it's all confusing. My replacement in 91b2978a34807 from 
SetPageDirty -> folio_set_dirty() was correct. It only operates on anon 
folios, likely that's why folio_set_dirty() is okay there.

Oh my.

--
Cheers,

David / dhildenb