Received: by 10.223.164.221 with SMTP id h29csp1813926wrb; Thu, 2 Nov 2017 01:04:06 -0700 (PDT) X-Google-Smtp-Source: ABhQp+SxpUifmAHmzjrDv8qEK7/SvhIAoSUB7jINyXsdrJUw50VHKo+un3+eU7humRpi6r4oANol X-Received: by 10.98.147.23 with SMTP id b23mr2818860pfe.5.1509609845985; Thu, 02 Nov 2017 01:04:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509609845; cv=none; d=google.com; s=arc-20160816; b=Iv9wia9wmqo+xa+fFtNbYIHgc43B6IgmLAf2V/ARxwz1F1mPANsWXEHoYHb/O8WOaQ Zf2tV4Z6hoAnyBlEyzMM0duA5NjW09Y7OI+e4wF5KqhZ+V/umiQoue4LDV1bea4sUorx zYYuqD+5QqRwd8YiH5bfYAUXIXT6dEzIqyjzW3AsfLtVNJUGF2g8ahbVc/XAkPD46byu BEaMRXW2vNKZT5l/jNgPmIaFDHj6WIQb0eZTFK9nPB6fePWsKnsNVsppDea98zB+Xj/9 eJYzc5sVmI7Ar1Iaxj/thAaxthoB+Puo4WZj46OarUJa+g4WHTHVE1cK7rn6PF690XVO VqKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=74YKjaWGzixvTYxuCvFUYo2vioQctzzQVt0+NKzXthI=; b=OSRZ9T7R58LRUgOs6i1RJVWaZhLy6UrqM1smG+JFIjfYwRoVM9RJB2qDw5lLlh4fDH yFeitBSCb4OUOKrXIDMnfStuygU6YLR4uKYS/cQrw5Li3kg3xRiF2NIHfEDRNOAEnT4w bYs1lR0vJ7dHy/DZCC2qcpYsdJvypbwk3aCw1NJ7CwQ5FkbOlEO0Jx2hNrg0XX1JdVw6 zTqRTqn9IO3PYCW8FJN48yzSeLjEgr2BCITCX7YAgBs+1lG6YC4b3H7Ax6RH7k8RjgTL IXTwtCuxt2dXCwaRtU6BG96tegBBAc3DZ3P5hqQzi+VAfzIsi3XJBoBdSxfMOHQ6sQlO ZeWA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u63si2795928pgd.551.2017.11.02.01.03.52; Thu, 02 Nov 2017 01:04:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755514AbdKBIC6 (ORCPT + 99 others); Thu, 2 Nov 2017 04:02:58 -0400 Received: from mx2.suse.de ([195.135.220.15]:58942 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752567AbdKBICw (ORCPT ); Thu, 2 Nov 2017 04:02:52 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0CEAFAAC5; Thu, 2 Nov 2017 08:02:51 +0000 (UTC) Date: Thu, 2 Nov 2017 09:02:49 +0100 From: Michal Hocko To: Jaewon Kim Cc: akpm@linux-foundation.org, vbabka@suse.cz, minchan@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, jaewon31.kim@gmail.com Subject: Re: [PATCH] mm: page_ext: allocate page extension though first PFN is invalid Message-ID: <20171102080249.uxxq4ko3cc2wgnbz@dhcp22.suse.cz> References: <20171102063507.25671-1-jaewon31.kim@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171102063507.25671-1-jaewon31.kim@samsung.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 02-11-17 15:35:07, Jaewon Kim wrote: > online_page_ext and page_ext_init allocate page_ext for each section, but > they do not allocate if the first PFN is !pfn_present(pfn) or > !pfn_valid(pfn). Then section->page_ext remains as NULL. lookup_page_ext > checks NULL only if CONFIG_DEBUG_VM is enabled. For a valid PFN, > __set_page_owner will try to get page_ext through lookup_page_ext. > Without CONFIG_DEBUG_VM lookup_page_ext will misuse NULL pointer as value > 0. This incurrs invalid address access. > > This is the panic example when PFN 0x100000 is not valid but PFN 0x13FC00 > is being used for page_ext. section->page_ext is NULL, get_entry returned > invalid page_ext address as 0x1DFA000 for a PFN 0x13FC00. > > <1>[ 11.618085] Unable to handle kernel paging request at virtual address 01dfa014 > <1>[ 11.618140] pgd = ffffffc0c6dc9000 > <1>[ 11.618174] [01dfa014] *pgd=0000000000000000, *pud=0000000000000000 > <4>[ 11.618240] ------------[ cut here ]------------ > <2>[ 11.618278] Kernel BUG at ffffff80082371e0 [verbose debug info unavailable] > <0>[ 11.618338] Internal error: Oops: 96000045 [#1] PREEMPT SMP > <4>[ 11.618381] Modules linked in: > <4>[ 11.618524] task: ffffffc0c6ec9180 task.stack: ffffffc0c6f40000 > <4>[ 11.618569] PC is at __set_page_owner+0x48/0x78 > <4>[ 11.618607] LR is at __set_page_owner+0x44/0x78 > <4>[ 11.626025] [] __set_page_owner+0x48/0x78 > <4>[ 11.626071] [] get_page_from_freelist+0x880/0x8e8 > <4>[ 11.626118] [] __alloc_pages_nodemask+0x14c/0xc48 > <4>[ 11.626165] [] __do_page_cache_readahead+0xdc/0x264 > <4>[ 11.626214] [] filemap_fault+0x2ac/0x550 > <4>[ 11.626259] [] ext4_filemap_fault+0x3c/0x58 > <4>[ 11.626305] [] __do_fault+0x80/0x120 > <4>[ 11.626347] [] handle_mm_fault+0x704/0xbb0 > <4>[ 11.626393] [] do_page_fault+0x2e8/0x394 > <4>[ 11.626437] [] do_mem_abort+0x88/0x124 > > Though the first page is not valid, page_ext could be useful for other > pages in the section. But checking all PFNs in a section may be time > consuming job. Let's check each (section count / 16) PFN, then prepare > page_ext if any PFN is present or valid. And remove the CONFIG_DEBUG_VM in > lookup_page_ext to avoid panic. So I would split this patch into two. First one to address the panic which sounds like a stable material and then the enhancement which will most likely need a further discussion. > Signed-off-by: Jaewon Kim > --- > mm/page_ext.c | 29 ++++++++++++++++++++++------- > 1 file changed, 22 insertions(+), 7 deletions(-) > > diff --git a/mm/page_ext.c b/mm/page_ext.c > index 32f18911deda..bf9c99beb312 100644 > --- a/mm/page_ext.c > +++ b/mm/page_ext.c > @@ -124,7 +124,6 @@ struct page_ext *lookup_page_ext(struct page *page) > struct page_ext *base; > > base = NODE_DATA(page_to_nid(page))->node_page_ext; > -#if defined(CONFIG_DEBUG_VM) > /* > * The sanity checks the page allocator does upon freeing a > * page can reach here before the page_ext arrays are > @@ -133,7 +132,6 @@ struct page_ext *lookup_page_ext(struct page *page) > */ > if (unlikely(!base)) > return NULL; > -#endif > index = pfn - round_down(node_start_pfn(page_to_nid(page)), > MAX_ORDER_NR_PAGES); > return get_entry(base, index); > @@ -198,7 +196,6 @@ struct page_ext *lookup_page_ext(struct page *page) > { > unsigned long pfn = page_to_pfn(page); > struct mem_section *section = __pfn_to_section(pfn); > -#if defined(CONFIG_DEBUG_VM) > /* > * The sanity checks the page allocator does upon freeing a > * page can reach here before the page_ext arrays are > @@ -207,7 +204,6 @@ struct page_ext *lookup_page_ext(struct page *page) > */ > if (!section->page_ext) > return NULL; > -#endif > return get_entry(section->page_ext, pfn); > } > > @@ -312,7 +308,17 @@ static int __meminit online_page_ext(unsigned long start_pfn, > } > > for (pfn = start; !fail && pfn < end; pfn += PAGES_PER_SECTION) { > - if (!pfn_present(pfn)) > + unsigned long t_pfn = pfn; > + bool present = false; > + > + while (t_pfn < ALIGN(pfn + 1, PAGES_PER_SECTION)) { > + if (pfn_present(t_pfn)) { > + present = true; > + break; > + } > + t_pfn = ALIGN(pfn + 1, PAGES_PER_SECTION >> 4); > + } > + if (!present) > continue; > fail = init_section_page_ext(pfn, nid); > } > @@ -391,8 +397,17 @@ void __init page_ext_init(void) > */ > for (pfn = start_pfn; pfn < end_pfn; > pfn = ALIGN(pfn + 1, PAGES_PER_SECTION)) { > - > - if (!pfn_valid(pfn)) > + unsigned long t_pfn = pfn; > + bool valid = false; > + > + while (t_pfn < ALIGN(pfn + 1, PAGES_PER_SECTION)) { > + if (pfn_valid(t_pfn)) { > + valid = true; > + break; > + } > + t_pfn = ALIGN(pfn + 1, PAGES_PER_SECTION >> 4); > + } > + if (!valid) > continue; > /* > * Nodes's pfns can be overlapping. > -- > 2.13.0 -- Michal Hocko SUSE Labs From 1582935025480239932@xxx Thu Nov 02 06:34:38 +0000 2017 X-GM-THRID: 1582935025480239932 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread