Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Date:   Tue, 7 Jun 2022 11:32:57 -0700
From:   Andrew Morton <akpm@linux-foundation.org>
To:     Miaohe Lin <linmiaohe@huawei.com>
Cc:     <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
        Joao Martins <joao.m.martins@oracle.com>
Subject: Re: [PATCH] mm/page_alloc: make calling prep_compound_head more
 reliable
Message-Id: <20220607113257.84b1bdd993f19be26b8c4944@linux-foundation.org>
In-Reply-To: <20220607144157.36411-1-linmiaohe@huawei.com>
References: <20220607144157.36411-1-linmiaohe@huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk


Let's cc Joao.

On Tue, 7 Jun 2022 22:41:57 +0800 Miaohe Lin <linmiaohe@huawei.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,