Received: by 10.223.164.202 with SMTP id h10csp275378wrb; Wed, 29 Nov 2017 22:05:36 -0800 (PST) X-Google-Smtp-Source: AGs4zMZAOFs9iJYgad9HYSMrif3s7ePnkuAmvFOkoRP4JsbHIcdfXh4H1pf5nT5wDbWedlSxvrvm X-Received: by 10.84.142.131 with SMTP id 3mr1476138plx.26.1512021936074; Wed, 29 Nov 2017 22:05:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1512021936; cv=none; d=google.com; s=arc-20160816; b=CVQHUH2NPDfnx0JbCNWQjxHGe227pEwtlD746yWVE3a+39WDrO9Q+R1QJs9IQi/NVW Yov5GzHd82Ziq0SZpFjmaZJ5aqD2B15BeDvHtFpdbfqnUuCB0wkUSamcFZfJI8/CxMFO 5PG2FN0Esf9THAStv3DGgWQs44HROtTV5BSiUaK/8JOEViS/tFbm4qpmBnMRzUGCG0Ev PrsFkF7ZIU6O9NWYNkfcu9bC22ifHituI9fz/f5MrEP4b6hVZ/AlPv4hwau5fxwWJWbs CEOy/2ao009tOiDwuMVWkdqCXwnRjGh8mrfkWXIMfE2F7/qZqyTpvQ7/mLdjkX444wzj vtPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-disposition :mime-version:message-id:subject:cc:to:from:date :arc-authentication-results; bh=XHKFusbg5ROGmqEs47TnPTq5UslF4ESbaYeJUz26LEQ=; b=QSRxwRjblVKffHq6MEeHL0+hsIxoc122k1M7oNRKBYwvIq4P0JtenDoK6L/iq8LAuw +lttXYurJrDly4KdGPa4ifgNS1j5nbOeeLpMNI1kLAh3A+GCDmeT2T/bBz+E/3HOL9hX x3Z6hcVX2IltqPU90mD+zXr9PomEIQaihn7iKGXAsNRNNYY+Amb6Sm7RN8T8bbfWbg/K 132eLJQYOHdVdrETVXjP/oXUGCd7cz7ogkN5swzENwRg1GdBgVmMo4FQ7e0xlHYCIRS8 NI9e1IRAmj3cNiaNY3g+NwPDqlF81paVcRzwrh7KNd7x3XjMFKoa+LEKnhhVUlkm6S5J /zJw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1si2526362plz.723.2017.11.29.22.05.22; Wed, 29 Nov 2017 22:05:36 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751421AbdK3GEk (ORCPT + 99 others); Thu, 30 Nov 2017 01:04:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55292 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750891AbdK3GEj (ORCPT ); Thu, 30 Nov 2017 01:04:39 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 384EEC057FA6; Thu, 30 Nov 2017 06:04:39 +0000 (UTC) Received: from dhcp-128-65.nay.redhat.com (ovpn-12-147.pek2.redhat.com [10.72.12.147]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 27A9B60621; Thu, 30 Nov 2017 06:04:35 +0000 (UTC) Date: Thu, 30 Nov 2017 14:04:31 +0800 From: Dave Young To: linux-kernel@vger.kernel.org Cc: pasha.tatashin@oracle.com, linux-mm@kvack.org, akpm@linux-foundation.org Subject: [PATCH] mm: check pfn_valid first in zero_resv_unavail Message-ID: <20171130060431.GA2290@dhcp-128-65.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 30 Nov 2017 06:04:39 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org With latest kernel I get below bug while testing kdump: [ 0.000000] BUG: unable to handle kernel paging request at ffffea00034b1040 [ 0.000000] IP: zero_resv_unavail+0xbd/0x126 [ 0.000000] PGD 37b98067 P4D 37b98067 PUD 37b97067 PMD 0 [ 0.000000] Oops: 0002 [#1] SMP [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.15.0-rc1+ #316 [ 0.000000] Hardware name: LENOVO 20ARS1BJ02/20ARS1BJ02, BIOS GJET92WW (2.42 ) 03/03/2017 [ 0.000000] task: ffffffff81a0e4c0 task.stack: ffffffff81a00000 [ 0.000000] RIP: 0010:zero_resv_unavail+0xbd/0x126 [ 0.000000] RSP: 0000:ffffffff81a03d88 EFLAGS: 00010006 [ 0.000000] RAX: 0000000000000000 RBX: ffffea00034b1040 RCX: 0000000000000010 [ 0.000000] RDX: 0000000000000000 RSI: 0000000000000092 RDI: ffffea00034b1040 [ 0.000000] RBP: 00000000000d2c41 R08: 00000000000000c0 R09: 0000000000000a0d [ 0.000000] R10: 0000000000000002 R11: 0000000000007f01 R12: ffffffff81a03d90 [ 0.000000] R13: ffffea0000000000 R14: 0000000000000063 R15: 0000000000000062 [ 0.000000] FS: 0000000000000000(0000) GS:ffffffff81c73000(0000) knlGS:0000000000000000 [ 0.000000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.000000] CR2: ffffea00034b1040 CR3: 0000000037609000 CR4: 00000000000606b0 [ 0.000000] Call Trace: [ 0.000000] ? free_area_init_nodes+0x640/0x664 [ 0.000000] ? zone_sizes_init+0x58/0x72 [ 0.000000] ? setup_arch+0xb50/0xc6c [ 0.000000] ? start_kernel+0x64/0x43d [ 0.000000] ? secondary_startup_64+0xa5/0xb0 [ 0.000000] Code: c1 e8 0c 48 39 d8 76 27 48 89 de 48 c1 e3 06 48 c7 c7 7a 87 79 81 e8 b0 c0 3e ff 4c 01 eb b9 10 00 00 00 31 c0 48 89 df 49 ff c6 ab eb bc 6a 00 49 c7 c0 f0 93 d1 81 31 d2 83 ce ff 41 54 49 [ 0.000000] RIP: zero_resv_unavail+0xbd/0x126 RSP: ffffffff81a03d88 [ 0.000000] CR2: ffffea00034b1040 [ 0.000000] ---[ end trace f5ba9e8f73c7ee26 ]--- This is introduced with below commit: commit a4a3ede2132ae0863e2d43e06f9b5697c51a7a3b Author: Pavel Tatashin Date: Wed Nov 15 17:36:31 2017 -0800 mm: zero reserved and unavailable struct pages The reason is some efi reserved boot ranges is not reported in E820 ram. In my case it is a bgrt buffer: efi: mem00: [Boot Data |RUN| | | | | | | |WB|WT|WC|UC] range=[0x00000000d2c41000-0x00000000d2c85fff] (0MB) Use "add_efi_memmap" can workaround the problem with another fix: https://lkml.org/lkml/2017/11/30/5 In zero_resv_unavail it would be better to check pfn_valid first before zero the page struct. This fixes the problem and potential other similar problems. Signed-off-by: Dave Young --- mm/page_alloc.c | 2 ++ 1 file changed, 2 insertions(+) --- linux.orig/mm/page_alloc.c +++ linux/mm/page_alloc.c @@ -6253,6 +6253,8 @@ void __paginginit zero_resv_unavail(void pgcnt = 0; for_each_resv_unavail_range(i, &start, &end) { for (pfn = PFN_DOWN(start); pfn < PFN_UP(end); pfn++) { + if (!pfn_valid(pfn)) + continue; mm_zero_struct_page(pfn_to_page(pfn)); pgcnt++; } From 1586582608117555660@xxx Tue Dec 12 12:51:24 +0000 2017 X-GM-THRID: 1586582608117555660 X-Gmail-Labels: Inbox,Category Promotions,HistoricalUnread