From patchwork Fri Dec 9 13:15:12 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xie Yisheng X-Patchwork-Id: 9468215 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5B18260586 for ; Fri, 9 Dec 2016 13:28:15 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4D0C12856B for ; Fri, 9 Dec 2016 13:28:15 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 41B1328576; Fri, 9 Dec 2016 13:28:15 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id D70C92856B for ; Fri, 9 Dec 2016 13:28:14 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1cFLC3-0001Ms-6z; Fri, 09 Dec 2016 13:26:31 +0000 Received: from szxga01-in.huawei.com ([58.251.152.64]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1cFLBy-0001Im-Bm for linux-arm-kernel@lists.infradead.org; Fri, 09 Dec 2016 13:26:28 +0000 Received: from 172.24.1.47 (EHLO szxeml426-hub.china.huawei.com) ([172.24.1.47]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWG86038; Fri, 09 Dec 2016 21:15:18 +0800 (CST) Received: from [127.0.0.1] (10.177.29.40) by szxeml426-hub.china.huawei.com (10.82.67.181) with Microsoft SMTP Server id 14.3.235.1; Fri, 9 Dec 2016 21:15:14 +0800 Subject: Re: [PATCH v2] arm64: mm: Fix memmap to be initialized for the entire section To: Hanjun Guo , Ard Biesheuvel References: <1480530091-1092-1-git-send-email-rrichter@cavium.com> <584AA257.3080608@linaro.org> From: Yisheng Xie Message-ID: Date: Fri, 9 Dec 2016 21:15:12 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <584AA257.3080608@linaro.org> X-Originating-IP: [10.177.29.40] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20161209_052627_084320_8B48FE44 X-CRM114-Status: GOOD ( 12.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , David Daney , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , Robert Richter , "linux-arm-kernel@lists.infradead.org" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On 2016/12/9 20:23, Hanjun Guo wrote: > On 12/09/2016 08:19 PM, Ard Biesheuvel wrote: >> On 9 December 2016 at 12:14, Yisheng Xie wrote: >>> Hi Robert, >>> We have merged your patch to 4.9.0-rc8, however we still meet the similar problem >>> on our D05 board: >>> >> >> To be clear: does this issue also occur on D05 *without* the patch? > > It boots ok on D05 without this patch. > > But I think the problem Robert described in the commit message is > still there, just not triggered in the boot. we met this problem > when having LTP stress memory test and hit the same BUG_ON. > That's right. for D05's case, when trigger the BUG_ON on: 1863 VM_BUG_ON(page_zone(start_page) != page_zone(end_page)); the end_page is not nomap, but BIOS reserved. here is the log I got: [ 0.000000] efi: 0x00003fc00000-0x00003fffffff [Reserved | | | | | | | | | | | | ] [...] [ 5.081443] move_freepages: phys(start_page: 0x20000000,end_page:0x3fff0000) For invalid pages, their zone and node information is not initialized, and it do have risk to trigger the BUG_ON, so I have a silly question, why not just change the BUG_ON: ----------- Thanks, Yisheng Xie > Thanks > Hanjun > > . > diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 6de9440..af199b8 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1860,12 +1860,13 @@ int move_freepages(struct zone *zone, * Remove at a later date when no bug reports exist related to * grouping pages by mobility */ - VM_BUG_ON(page_zone(start_page) != page_zone(end_page)); + VM_BUG_ON(early_pfn_valid(start_page) && early_pfn_valid(end_page) && + page_zone(start_page) != page_zone(end_page)); #endif for (page = start_page; page <= end_page;) { /* Make sure we are not inadvertently changing nodes */ - VM_BUG_ON_PAGE(page_to_nid(page) != zone_to_nid(zone), page); + VM_BUG_ON_PAGE(early_pfn_valid(page) && (page_to_nid(page) != zone_to_nid(zone)), page); if (!pfn_valid_within(page_to_pfn(page))) { page++;