From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755634AbcJFO1O (ORCPT ); Thu, 6 Oct 2016 10:27:14 -0400 Received: from mail-by2nam03on0075.outbound.protection.outlook.com ([104.47.42.75]:63695 "EHLO NAM03-BY2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751055AbcJFO1L (ORCPT ); Thu, 6 Oct 2016 10:27:11 -0400 X-Greylist: delayed 14429 seconds by postgrey-1.27 at vger.kernel.org; Thu, 06 Oct 2016 10:27:11 EDT Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Robert.Richter@cavium.com; From: Robert Richter To: Catalin Marinas , Will Deacon CC: Ard Biesheuvel , David Daney , Mark Rutland , Hanjun Guo , , , Robert Richter , Subject: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section Date: Thu, 6 Oct 2016 11:52:07 +0200 Message-ID: <1475747527-32387-1-git-send-email-rrichter@cavium.com> X-Mailer: git-send-email 2.7.0.rc3 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [92.229.86.66] X-ClientProxiedBy: AM5PR0501CA0021.eurprd05.prod.outlook.com (10.164.187.31) To CY1PR07MB2345.namprd07.prod.outlook.com (10.166.194.144) X-MS-Office365-Filtering-Correlation-Id: 1c9e846f-20a2-4fa5-c951-08d3edce91fd X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2345;2:HM7ar0lkJ2uR+6ijyP8kDMKKYnq/Yxlczevm034qC1nXwCUlQu1OSe3vR5oQoL24n9bD3+4GzHBeRJTp4vgH7/WsCJfOQXqkWtg48vxTGUuXRBZepfrHPATJOcsHEGMDC0qS1/LqKq39U3X5yAiWuiWfnq43TvF25MeO5etim1D5TwmHedtza5/6ua3ULh2C60h/yIY/sOC/atFnAJERHg==;3:V9LAPVkA6pNUULvL0efdK5j+/YLb4R5QoixW/HzTeEto/gS0jf8oeAwwrD6au6gJAVjCvAMfrefHofIbbngCFnKJYw+pHf9wrMKYni88po/kngprXtFs+ycWuVWxJoUwoMHbEciDU++HNwU7j3GMTg==;25:i2x1lBqebwaIaYKZgCtvUwoSQWhhEQDpJqCrTNE9Ee8YkK5iMnDc7uNVBnX4PtWcfxUjz/HeRiJW4zsXXkriX3sMC9s3YjTUOGCTdDz4ion3tAZjk1fpYBRCPrPLEDmH6IzPHRMmjWyibjCSyC7vxs33b5XU5iiCnfYbwXYiN2S1vODWqd5XNlm5N5VIlX7ejsTqjkWg/Mz4OmDJXl134AaIdw1cRaiQGr3wR5KVPc9hzDuFJRPcIDRMaj2JWApfBemTRBWI49kq3Zc93hloVJsRhfIIWVGBPCZaH2QDRJ6aVqld3d59NVILai6f2BabKFxJOz9L2oabqgV1RcorBOscAkaN39XAcaIfILoEnAZDfyZ5ifi/jY83FlbcT48fNrHDPW5gluxMp9/iR9IECQDON+P8fKLlqEEMYM0gKIupwymKe+cSiKL0w9zQsQhD X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2345; X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2345;31:YUnqy64VP6EnqTSxjTmtyHvFyR64L8fJmBx3kS9kLwxKe1mm2rjUGfX+r6K7ZkpmyL3mSWXUkVwYSfmqrtwdWm/jZpDmgcwglgEGaHGF4vdi//nlMUh1INIhSb0oLrkjzUYlW8BXIImkYE32MRw4XndKswaXxKw1AgZf81jjYZbmUIp8PiPV76ZlaLiZrGBIvmw9Qjy26ULLoxQHNle5UA63SrEW0WUej1i5voVOS+UyMNeJMYX+ISm/NSWF0A8F;20:3jmvyK/Zif2aFXH56KHUK18gIG56XS1TGMV3gdSCKZ40Zhw1AxXS6XmKdEba8tS/f+44ClvDNDC72E2k0vITwbO2P09CU+KAyptH8PBg6pYlqVv8xOmX4gjHgZ3OXTGngXsA1Uv028H8GyvIYWjDMwcP2eRp0Zfut6yGm4GSGEqRZHFLc7o5EPfNQ8eUmjyrbvrCW0E3N31bjQMrsnqTjFgFEHaINIM/uA1n0Ex0Qs8yKXwiDwYzWToAOfDAtHfCY1cRclE6JdhRliTyQZkNYSJprjsRwwQ74NOxoBdWRTjRP7cwdP0PAdfhoRuo+GrNTP+2gmk7mjCscjCDZmhqjbd8kJuX70+HFnyqZ9Bvz8VNSs6Yzjd+vWqsiJ0coL87pwV9/tSOI05kzSGPo5Am4O+BmwcFZHPW9fTtTjd0F50n2y511KBKHQLafAdSvlLgFwU/WBuRDA25EY4sjddLbnOe8OVOASa1tCdty899Ex5EwRS+uIpNSzLghrJ2H7Ql X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(20558992708506); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001);SRVR:CY1PR07MB2345;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2345; X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2345;4:bZ7o9+PXK/7EI6VgtRfdnoC8XF51elKMpCRxGY4HZRAn1nV4UWvUGnd90bEH5oMKdJbuDZjN85EpBLuFJeIXQUHDdNAlcLSNHxvcK6kNSahvWaoMy0Ijubou/GIvc+YPlL8ya1eL3TD8kaOXJqPVNpbdYcCCx0W1J7El39tc8Ebms/0CaYYQlqgjWqLE/Avx3DXEU33KsYSPc2sjf6JGA8Kqkd4JT56RU2FJqmwQ8xd/N8GMTk97bLyjW/tdRKkEap7ffnw9nliFmQCiGSnn+hGtzSz+s5wEsq7yopfWcg8z1+wiaWFrNlTPHmn7YJE0r9ijR5TieW9IQufwSaUd6lM911AsLPj4O+evSJs8ssNBesM/jp55YrcOPMED4tG7vZy9jRuVhvOpG1JsPMjwnbzze1JprL4ToN2mrRXeQ0oiyLP9Cr6UKlgMiPe/dupO5xWE/40oUL8SQCaFxRf81g== X-Forefront-PRVS: 00872B689F X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(7916002)(199003)(189002)(7846002)(7736002)(305945005)(81156014)(47776003)(66066001)(8676002)(4326007)(19580395003)(81166006)(2906002)(50466002)(48376002)(50986999)(101416001)(19580405001)(77096005)(575784001)(42186005)(3846002)(6116002)(36756003)(189998001)(97736004)(586003)(5003940100001)(5001770100001)(5660300001)(105586002)(229853001)(106356001)(92566002)(33646002)(50226002)(68736007);DIR:OUT;SFP:1101;SCL:1;SRVR:CY1PR07MB2345;H:rric.localdomain;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;CY1PR07MB2345;23:1FxatQmPhFaYagw/StmEyRoDQhkc6kGvHlyp8HEc0?= =?us-ascii?Q?awT8S3HZzLzzFpV6oxb/7+dVz9fle441DwJzVNpm41uN9dvWWMqVKlZP34SK?= =?us-ascii?Q?Sx3026wBn9X9t69/Pp8tb1Q8vjD43JxCr83sZYakP9o0iN+nvzHbN0x/WxhY?= =?us-ascii?Q?bBVvmLOKhXnu/s6WdAfQQW/6cO6K0yMRpa6zp64CJVERkXbb+hj40z3yHxRY?= =?us-ascii?Q?/YwSMNWGOtm33jeVyv1tMY45h82D3A/akdtG+h1LwFf2NjFv+fji0xuo2RTW?= =?us-ascii?Q?DCtnZGt4KJMfb5dPUtJL2kSLsjdQV7MDua/oiL+h0m6YMmlaE2BT+Nkv76e9?= =?us-ascii?Q?9zmjOs/uMjG2kLuqZnu7QYezmNDMDaBcMWBxRTTEQuBeELuEO58ykwpo3KvH?= =?us-ascii?Q?1hmxLmVUwdIF2e45oXGrUqLvRkyhEBcNJuCKPZzJSFZIgOYP3TcIZ5Xe3gai?= =?us-ascii?Q?6Z5VVn8oSzbKirpVZfexsCxddISl+gsj9VJY1pgSrLQzTRn8gCmGM4znuXMJ?= =?us-ascii?Q?JyPNZrsb574/Nc8HjTcBHRqMQS0stzUUo5T53Z1e3Hgf4FyjKF7FYP+2h5NF?= =?us-ascii?Q?EKInAgzktNOa1nhcYqKZjj0GXXHb2FIuE0kUFAQYRkxM02Sf+ANTW6CD6034?= =?us-ascii?Q?RWQhWeeRYy/YvpkxDW9JZ3yy7MDDkWGTL9Lsc2uqaiQHZwv4UDTRyOlJ8tZf?= =?us-ascii?Q?30MyZxTaYeLQM5ARBTRtjbNlYHzLL/WWEfRtoifEQSITVSqCt26QgomPV7zM?= =?us-ascii?Q?10wz2gPxJqcCCxiGkPntL1awBPZW88PqRVHiD3V7lgH2nqy9UMJeGfbExgZ7?= =?us-ascii?Q?pwKFFt55hTHf1V487x+YmwCjnsuGvL5HhU5QAmf+WA57R5QIqmzFgYddZBvV?= =?us-ascii?Q?+afEmzQ7XT2rQaOugDyReOVs+AOfDUcpSIVuhsg/2rhZSR0YDOMay5G1iG4E?= =?us-ascii?Q?u6ngwCJxgI0ia8ME+iKvI3OHdLKc9tUBkaJA3pDJZMaS/iGQJUi3GSvPI/LV?= =?us-ascii?Q?5ckqy6MpcYt5kRqjFcrEUiqYOd5tUmxrbHuE0saIUKLYA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2345;6:GhDQ7HH7hKAoees/Ue6Vzzu6X4V8+yY4kFDEMdzuxqRV9OSKOrL5quUFuY/3PtJIPVv/dKjZgaEqSZnaJXiI+zmWLXWAtdQvF55Mk1mqNU57jyoTbtClZLTvlM26cRftTKYxTkbrvtsRM/M/C9m22+uFCV/OwqCvvZ9/ry/Lc54DZgX7ClTVo3b+EKGb5Ma8qAhmdPjzgoN53M5TlhfMOD0i5iJk7/1fgaMuwhjCT1ttAmhf75pjL3Pcgz+i7T46m6ovXNSLyHUaXPppefNQw5nfYOQVbGVOfqMLhT7YRCOfSQGKtGDOAJpFy2RtW9Rg;5:M8Luc2SsMPzuQL4VNu9jWQto9drWeSKWlIW9uanIJ+Jhib5Mcc4o7xuKtX0HuaB9BEEUrVLZPCy6uuzNDsF+Bzc4CuRPk6Wx7i4hmPFsw5pHxJM4C2V5gKRDtWH4kPpawUFg51foOs1PaYooFPnB7hkQw7b4JumUAcHpxq2O01U=;24:ByyRsRX0Ok1ldR6Ne5cgvZmv4ytVxfKeTVI1n+w0E9NhxqddrnXn6n0Dgt8vkANwFtzb4oHRZS/4VDGZtsNzvyLNTSnd/QAr22yBGYmE1Jc=;7:F0dtajPF7ROPOBoaEus0/mlKOnzQDeJ/4XT6ph6+7EAhWlhgR4NzCqshnaT0Cvct2I9jGSrC2cSbbzrALB2nLzAcd4xM1OQExFHGWecpAcCzTmmFXyv5+5aOrThJTQveNIbEmPDz4/zVPLKZ9wFoFVk2EdWjzpIE0tKEg7YkgMaPiV4HU/USaSCZmLXH1OTvDjGXSVGPKQvNSHhH2juPRxvgcDx3o+GeQB9TvI1FpuYoTmgBjHlLxkdl3dFl5630BtJWjfv4s28yqJcl6MBw19lANARFskB4HJsE3/QYlGfDUg1itQjJSmM3Q9kqGqhqfIi5SDJQikdPgvwW4l6clA== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cavium.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Oct 2016 09:53:03.7849 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2345 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org There is a memory setup problem on ThunderX systems with certain memory configurations. The symptom is kernel BUG at mm/page_alloc.c:1848! This happens for some configs with 64k page size enabled. The bug triggers for page zones with some pages in the zone not assigned to this particular zone. In my case some pages that are marked as nomap were not reassigned to the new zone of node 1, so those are still assigned to node 0. The reason for the mis-configuration is a change in pfn_valid() which reports pages marked nomap as invalid: 68709f45385a arm64: only consider memblocks with NOMAP cleared for linear mapping This causes pages marked as nomap being no long reassigned to the new zone in memmap_init_zone() by calling __init_single_pfn(). Fixing this by restoring the old behavior of pfn_valid() to use memblock_is_memory(). Also changing users of pfn_valid() in arm64 code to use memblock_is_map_memory() where necessary. This only affects code in ioremap.c. The code in mmu.c still can use the new version of pfn_valid(). Should be marked stable v4.5.. Signed-off-by: Robert Richter --- arch/arm64/mm/init.c | 2 +- arch/arm64/mm/ioremap.c | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index bbb7ee76e319..25b8659c2a9f 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -147,7 +147,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max) #ifdef CONFIG_HAVE_ARCH_PFN_VALID int pfn_valid(unsigned long pfn) { - return memblock_is_map_memory(pfn << PAGE_SHIFT); + return memblock_is_memory(pfn << PAGE_SHIFT); } EXPORT_SYMBOL(pfn_valid); #endif diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c index 01e88c8bcab0..c17c220b0c48 100644 --- a/arch/arm64/mm/ioremap.c +++ b/arch/arm64/mm/ioremap.c @@ -21,6 +21,7 @@ */ #include +#include #include #include #include @@ -55,7 +56,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size, /* * Don't allow RAM to be mapped. */ - if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr)))) + if (WARN_ON(memblock_is_map_memory(phys_addr))) return NULL; area = get_vm_area_caller(size, VM_IOREMAP, caller); @@ -96,7 +97,7 @@ EXPORT_SYMBOL(__iounmap); void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size) { /* For normal memory we already have a cacheable mapping. */ - if (pfn_valid(__phys_to_pfn(phys_addr))) + if (memblock_is_map_memory(phys_addr)) return (void __iomem *)__phys_to_virt(phys_addr); return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL), -- 2.7.0.rc3 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Richter Subject: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section Date: Thu, 6 Oct 2016 11:52:07 +0200 Message-ID: <1475747527-32387-1-git-send-email-rrichter@cavium.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Catalin Marinas , Will Deacon Cc: Mark Rutland , linux-efi@vger.kernel.org, David Daney , Ard Biesheuvel , linux-kernel@vger.kernel.org, Robert Richter , Hanjun Guo , linux-arm-kernel@lists.infradead.org List-Id: linux-efi@vger.kernel.org There is a memory setup problem on ThunderX systems with certain memory configurations. The symptom is kernel BUG at mm/page_alloc.c:1848! This happens for some configs with 64k page size enabled. The bug triggers for page zones with some pages in the zone not assigned to this particular zone. In my case some pages that are marked as nomap were not reassigned to the new zone of node 1, so those are still assigned to node 0. The reason for the mis-configuration is a change in pfn_valid() which reports pages marked nomap as invalid: 68709f45385a arm64: only consider memblocks with NOMAP cleared for linear mapping This causes pages marked as nomap being no long reassigned to the new zone in memmap_init_zone() by calling __init_single_pfn(). Fixing this by restoring the old behavior of pfn_valid() to use memblock_is_memory(). Also changing users of pfn_valid() in arm64 code to use memblock_is_map_memory() where necessary. This only affects code in ioremap.c. The code in mmu.c still can use the new version of pfn_valid(). Should be marked stable v4.5.. Signed-off-by: Robert Richter --- arch/arm64/mm/init.c | 2 +- arch/arm64/mm/ioremap.c | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index bbb7ee76e319..25b8659c2a9f 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -147,7 +147,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max) #ifdef CONFIG_HAVE_ARCH_PFN_VALID int pfn_valid(unsigned long pfn) { - return memblock_is_map_memory(pfn << PAGE_SHIFT); + return memblock_is_memory(pfn << PAGE_SHIFT); } EXPORT_SYMBOL(pfn_valid); #endif diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c index 01e88c8bcab0..c17c220b0c48 100644 --- a/arch/arm64/mm/ioremap.c +++ b/arch/arm64/mm/ioremap.c @@ -21,6 +21,7 @@ */ #include +#include #include #include #include @@ -55,7 +56,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size, /* * Don't allow RAM to be mapped. */ - if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr)))) + if (WARN_ON(memblock_is_map_memory(phys_addr))) return NULL; area = get_vm_area_caller(size, VM_IOREMAP, caller); @@ -96,7 +97,7 @@ EXPORT_SYMBOL(__iounmap); void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size) { /* For normal memory we already have a cacheable mapping. */ - if (pfn_valid(__phys_to_pfn(phys_addr))) + if (memblock_is_map_memory(phys_addr)) return (void __iomem *)__phys_to_virt(phys_addr); return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL), -- 2.7.0.rc3 From mboxrd@z Thu Jan 1 00:00:00 1970 From: rrichter@cavium.com (Robert Richter) Date: Thu, 6 Oct 2016 11:52:07 +0200 Subject: [PATCH] arm64: mm: Fix memmap to be initialized for the entire section Message-ID: <1475747527-32387-1-git-send-email-rrichter@cavium.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org There is a memory setup problem on ThunderX systems with certain memory configurations. The symptom is kernel BUG at mm/page_alloc.c:1848! This happens for some configs with 64k page size enabled. The bug triggers for page zones with some pages in the zone not assigned to this particular zone. In my case some pages that are marked as nomap were not reassigned to the new zone of node 1, so those are still assigned to node 0. The reason for the mis-configuration is a change in pfn_valid() which reports pages marked nomap as invalid: 68709f45385a arm64: only consider memblocks with NOMAP cleared for linear mapping This causes pages marked as nomap being no long reassigned to the new zone in memmap_init_zone() by calling __init_single_pfn(). Fixing this by restoring the old behavior of pfn_valid() to use memblock_is_memory(). Also changing users of pfn_valid() in arm64 code to use memblock_is_map_memory() where necessary. This only affects code in ioremap.c. The code in mmu.c still can use the new version of pfn_valid(). Should be marked stable v4.5.. Signed-off-by: Robert Richter --- arch/arm64/mm/init.c | 2 +- arch/arm64/mm/ioremap.c | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index bbb7ee76e319..25b8659c2a9f 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -147,7 +147,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max) #ifdef CONFIG_HAVE_ARCH_PFN_VALID int pfn_valid(unsigned long pfn) { - return memblock_is_map_memory(pfn << PAGE_SHIFT); + return memblock_is_memory(pfn << PAGE_SHIFT); } EXPORT_SYMBOL(pfn_valid); #endif diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c index 01e88c8bcab0..c17c220b0c48 100644 --- a/arch/arm64/mm/ioremap.c +++ b/arch/arm64/mm/ioremap.c @@ -21,6 +21,7 @@ */ #include +#include #include #include #include @@ -55,7 +56,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size, /* * Don't allow RAM to be mapped. */ - if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr)))) + if (WARN_ON(memblock_is_map_memory(phys_addr))) return NULL; area = get_vm_area_caller(size, VM_IOREMAP, caller); @@ -96,7 +97,7 @@ EXPORT_SYMBOL(__iounmap); void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size) { /* For normal memory we already have a cacheable mapping. */ - if (pfn_valid(__phys_to_pfn(phys_addr))) + if (memblock_is_map_memory(phys_addr)) return (void __iomem *)__phys_to_virt(phys_addr); return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL), -- 2.7.0.rc3