[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210519212412.5653163f94904b141d5d74ce@linux-foundation.org>
Date: Wed, 19 May 2021 21:24:12 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Muchun Song <songmuchun@...edance.com>
Cc: osalvador@...e.de, mike.kravetz@...cle.com, mhocko@...e.com,
david@...hat.com, willy@...radead.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, duanxiongchun@...edance.com,
zhengqi.arch@...edance.com, fam.zheng@...edance.com,
Anshuman Khandual <anshuman.khandual@....com>
Subject: Re: [PATCH] mm: migrate: fix missing update page_private to
hugetlb_page_subpool
On Thu, 20 May 2021 10:59:49 +0800 Muchun Song <songmuchun@...edance.com> wrote:
> Since commit d6995da31122 ("hugetlb: use page.private for hugetlb specific
> page flags") converts page.private for hugetlb specific page flags. We
> should use hugetlb_page_subpool() to get the subpool pointer instead of
> page_private(). The commit forgot to update it in the page migration
> routine. So fix it.
>
> ...
>
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1290,7 +1290,7 @@ static int unmap_and_move_huge_page(new_page_t get_new_page,
> * page_mapping() set, hugetlbfs specific move page routine will not
> * be called and we could leak usage counts for subpools.
> */
> - if (page_private(hpage) && !page_mapping(hpage)) {
> + if (hugetlb_page_subpool(hpage) && !page_mapping(hpage)) {
> rc = -EBUSY;
> goto out_unlock;
> }
So it uses the wrong page*, so this isn't just a cosmetic fix. One
cannot tell from this changelog.
Please describe the runtime effects of this bug. Please always include
this information when fixing bugs. And when adding them.
Powered by blists - more mailing lists