[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220607113257.84b1bdd993f19be26b8c4944@linux-foundation.org>
Date: Tue, 7 Jun 2022 11:32:57 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Miaohe Lin <linmiaohe@...wei.com>
Cc: <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
Joao Martins <joao.m.martins@...cle.com>
Subject: Re: [PATCH] mm/page_alloc: make calling prep_compound_head more
reliable
Let's cc Joao.
On Tue, 7 Jun 2022 22:41:57 +0800 Miaohe Lin <linmiaohe@...wei.com> wrote:
> compound_pincount_ptr is stored at first tail page instead of second tail
> page now.
"now"? Some identifiable commit did this?
> And if it or some other field changes again in the future, data
> overwritten might happen. Calling prep_compound_head() outside the loop
> to prevent such possible issue. No functional change intended.
>
> ...
>
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6772,17 +6772,8 @@ static void __ref memmap_init_compound(struct page *head,
> __init_zone_device_page(page, pfn, zone_idx, nid, pgmap);
> prep_compound_tail(head, pfn - head_pfn);
> set_page_count(page, 0);
> -
> - /*
> - * The first tail page stores compound_mapcount_ptr() and
> - * compound_order() and the second tail page stores
> - * compound_pincount_ptr(). Call prep_compound_head() after
> - * the first and second tail pages have been initialized to
> - * not have the data overwritten.
> - */
> - if (pfn == head_pfn + 2)
> - prep_compound_head(head, order);
> }
> + prep_compound_head(head, order);
> }
>
> void __ref memmap_init_zone_device(struct zone *zone,
Powered by blists - more mailing lists