From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by kanga.kvack.org (Postfix) with ESMTP id DF9096B0032 for ; Fri, 23 Jan 2015 04:05:53 -0500 (EST) Received: by mail-wi0-f175.google.com with SMTP id fb4so1277571wid.2 for ; Fri, 23 Jan 2015 01:05:53 -0800 (PST) Received: from mx2.suse.de (cantor2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id ji6si640790wid.70.2015.01.23.01.05.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Jan 2015 01:05:51 -0800 (PST) Message-ID: <54C20EEC.1060809@suse.cz> Date: Fri, 23 Jan 2015 10:05:48 +0100 From: Vlastimil Babka MIME-Version: 1.0 Subject: Re: [PATCHv2] mm: Don't offset memmap for flatmem References: <1421804273-29947-1-git-send-email-lauraa@codeaurora.org> <1421888500-24364-1-git-send-email-lauraa@codeaurora.org> <20150122162021.aa861aeb53c22206a19ebbcb@linux-foundation.org> <54C196D0.6040900@codeaurora.org> In-Reply-To: <54C196D0.6040900@codeaurora.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott , Andrew Morton Cc: Srinivas Kandagatla , linux-arm-kernel@lists.infradead.org, Russell King - ARM Linux , ssantosh@kernel.org, Kevin Hilman , Arnd Bergman , Stephen Boyd , linux-mm@kvack.org, Kumar Gala , Mel Gorman On 01/23/2015 01:33 AM, Laura Abbott wrote: > On 1/22/2015 4:20 PM, Andrew Morton wrote: >> On Wed, 21 Jan 2015 17:01:40 -0800 Laura Abbott wrote: >> >>> Srinivas Kandagatla reported bad page messages when trying to >>> remove the bottom 2MB on an ARM based IFC6410 board >>> >>> BUG: Bad page state in process swapper pfn:fffa8 >>> page:ef7fb500 count:0 mapcount:0 mapping: (null) index:0x0 >>> flags: 0x96640253(locked|error|dirty|active|arch_1|reclaim|mlocked) >>> page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set >>> bad because of flags: >>> flags: 0x200041(locked|active|mlocked) >>> Modules linked in: >>> CPU: 0 PID: 0 Comm: swapper Not tainted 3.19.0-rc3-00007-g412f9ba-dirty #816 >>> Hardware name: Qualcomm (Flattened Device Tree) >>> [] (unwind_backtrace) from [] (show_stack+0x20/0x24) >>> [] (show_stack) from [] (dump_stack+0x80/0x9c) >>> [] (dump_stack) from [] (bad_page+0xc8/0x128) >>> [] (bad_page) from [] (free_pages_prepare+0x168/0x1e0) >>> [] (free_pages_prepare) from [] (free_hot_cold_page+0x3c/0x174) >>> [] (free_hot_cold_page) from [] (__free_pages+0x54/0x58) >>> [] (__free_pages) from [] (free_highmem_page+0x38/0x88) >>> [] (free_highmem_page) from [] (mem_init+0x240/0x430) >>> [] (mem_init) from [] (start_kernel+0x1e4/0x3c8) >>> [] (start_kernel) from [<80208074>] (0x80208074) >>> Disabling lock debugging due to kernel taint >>> >>> Removing the lower 2MB made the start of the lowmem zone to no longer >>> be page block aligned. IFC6410 uses CONFIG_FLATMEM where >>> alloc_node_mem_map allocates memory for the mem_map. alloc_node_mem_map >>> will offset for unaligned nodes with the assumption the pfn/page >>> translation functions will account for the offset. The functions for >>> CONFIG_FLATMEM do not offset however, resulting in overrunning >>> the memmap array. Just use the allocated memmap without any offset >>> when running with CONFIG_FLATMEM to avoid the overrun. >>> >> >> I don't think v2 addressed Vlastimil's review comment? >> > > We're still adding the offset to node_mem_map and then subtracting it from > just mem_map. Did I miss another comment somewhere? Yes that was addressed, thanks. But I don't feel comfortable acking it yet, as I have no idea if we are doing the right thing for CONFIG_HAVE_MEMBLOCK_NODE_MAP && CONFIG_FLATMEM case here. Also putting the CONFIG_FLATMEM && !CONFIG_HAVE_MEMBLOCK_NODE_MAP under the "if (page_to_pfn(mem_map) != pgdat->node_start_pfn)" will probably do the right thing, but looks like a weird test for this case here. I have no good suggestion though, so let's CC Mel who apparently wrote the ARCH_PFN_OFFSET correction? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org