linux-kernel - Re: [PATCH v2 19/46] mm/migrate: Add folio_migrate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YNTHGqKOu3d1/sCC@casper.infradead.org>
Date:   Thu, 24 Jun 2021 18:55:38 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     akpm@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 19/46] mm/migrate: Add folio_migrate_flags()

On Wed, Jun 23, 2021 at 10:28:52AM +0200, Christoph Hellwig wrote:
> >  	/*
> >  	 * Please do not reorder this without considering how mm/ksm.c's
> >  	 * get_ksm_page() depends upon ksm_migrate_page() and PageSwapCache().
> >  	 */
> > -	if (PageSwapCache(page))
> > -		ClearPageSwapCache(page);
> > -	ClearPagePrivate(page);
> > -	set_page_private(page, 0);
> > +	if (folio_swapcache(folio))
> > +		folio_clear_swapcache_flag(folio);
> > +	folio_clear_private_flag(folio);
> > +
> > +	/* page->private contains hugetlb specific flags */
> > +	if (!folio_hugetlb(folio))
> > +		folio->private = NULL;
> 
> Ymmm. Dosn't the ->private handling change now?  Given that you
> added a comment it seems intentional, but I do not understand why
> it changes as part of the conversion.

Oooh.  I was based on linux-next, and Linus asked me to stop doing that.
So I rebased on -rc4 (ish), but I inadvertently brought back some of the
changes which are currently in mmotm.  This one is from:

    mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page

which contains:

-       set_page_private(page, 0);
+
+       /* page->private contains hugetlb specific flags */
+       if (!PageHuge(page))
+               set_page_private(page, 0);

So, good catch, glad you're reviewing it so closely.  I'll fix this up
as part of rebasing this patch set on top of 14-rc1.  Obviously this
second patch set isn't for merging during this merge window, but I do
hope it can go into 5.15's merge window.

The only API change I intentionally brought back was:

    mm: memcontrol: remove the pgdata parameter of mem_cgroup_page_lruvec

You'll notice that my patches have:

+static inline struct lruvec *mem_cgroup_folio_lruvec(struct folio *folio)
+{
+       return mem_cgroup_page_lruvec(&folio->page, folio_pgdat(folio));
+}

where mmotm has:

-static inline struct lruvec *mem_cgroup_page_lruvec(struct page *page,
-                                               struct pglist_data *pgdat)
+static inline struct lruvec *mem_cgroup_page_lruvec(struct page *page)
 {
+       pg_data_t *pgdat = page_pgdat(page);


Probably I should have cherry-picked those prereq patches into my tree
to ease the rebasing (like I did our changes to set_page_dirty), but
I'm not 100% confident I'll get all their prereq patches.