From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755634AbdKBNch (ORCPT ); Thu, 2 Nov 2017 09:32:37 -0400 Received: from mx2.suse.de ([195.135.220.15]:55265 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755468AbdKBNcg (ORCPT ); Thu, 2 Nov 2017 09:32:36 -0400 Date: Thu, 2 Nov 2017 14:32:35 +0100 From: Michal Hocko To: Pavel Tatashin Cc: steven.sistare@oracle.com, daniel.m.jordan@oracle.com, akpm@linux-foundation.org, mgorman@techsingularity.net, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 1/1] mm: buddy page accessed before initialized Message-ID: <20171102133235.2vfmmut6w4of2y3j@dhcp22.suse.cz> References: <20171031155002.21691-1-pasha.tatashin@oracle.com> <20171031155002.21691-2-pasha.tatashin@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171031155002.21691-2-pasha.tatashin@oracle.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 31-10-17 11:50:02, Pavel Tatashin wrote: [...] > The problem happens in this path: > > page_alloc_init_late > deferred_init_memmap > deferred_init_range > __def_free > deferred_free_range > __free_pages_boot_core(page, order) > __free_pages() > __free_pages_ok() > free_one_page() > __free_one_page(page, pfn, zone, order, migratetype); > > deferred_init_range() initializes one page at a time by calling > __init_single_page(), once it initializes pageblock_nr_pages pages, it > calls deferred_free_range() to free the initialized pages to the buddy > allocator. Eventually, we reach __free_one_page(), where we compute buddy > page: > buddy_pfn = __find_buddy_pfn(pfn, order); > buddy = page + (buddy_pfn - pfn); > > buddy_pfn is computed as pfn ^ (1 << order), or pfn + pageblock_nr_pages. > Thefore, buddy page becomes a page one after the range that currently was > initialized, and we access this page in this function. Also, later when we > return back to deferred_init_range(), the buddy page is initialized again. > > So, in order to avoid this issue, we must initialize the buddy page prior > to calling deferred_free_range(). How come we didn't have this problem previously? I am really confused. > Signed-off-by: Pavel Tatashin > --- > mm/page_alloc.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 97687b38da05..f3ea06db3eed 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1500,9 +1500,17 @@ static unsigned long deferred_init_range(int nid, int zid, unsigned long pfn, > __init_single_page(page, pfn, zid, nid); > nr_free++; > } else { > - nr_pages += __def_free(&nr_free, &free_base_pfn, &page); > page = pfn_to_page(pfn); > __init_single_page(page, pfn, zid, nid); > + /* > + * We must free previous range after initializing the > + * first page of the next range. This is because first > + * page may be accessed in __free_one_page(), when buddy > + * page is computed: > + * buddy_pfn = pfn + pageblock_nr_pages > + */ > + deferred_free_range(free_base_pfn, nr_free); > + nr_pages += nr_free; > free_base_pfn = pfn; > nr_free = 1; > cond_resched(); > -- > 2.14.3 > -- Michal Hocko SUSE Labs