From: Laura Abbott <lauraa@codeaurora.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
linux-arm-kernel@lists.infradead.org,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
ssantosh@kernel.org, Kevin Hilman <khilman@linaro.org>,
Arnd Bergman <arnd@arndb.de>, Stephen Boyd <sboyd@codeaurora.org>,
linux-mm@kvack.org, Kumar Gala <galak@codeaurora.org>
Subject: Re: [PATCHv2] mm: Don't offset memmap for flatmem
Date: Thu, 22 Jan 2015 16:33:20 -0800 [thread overview]
Message-ID: <54C196D0.6040900@codeaurora.org> (raw)
In-Reply-To: <20150122162021.aa861aeb53c22206a19ebbcb@linux-foundation.org>
On 1/22/2015 4:20 PM, Andrew Morton wrote:
> On Wed, 21 Jan 2015 17:01:40 -0800 Laura Abbott <lauraa@codeaurora.org> 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)
>> [<c0218280>] (unwind_backtrace) from [<c0212be8>] (show_stack+0x20/0x24)
>> [<c0212be8>] (show_stack) from [<c0af7124>] (dump_stack+0x80/0x9c)
>> [<c0af7124>] (dump_stack) from [<c0301570>] (bad_page+0xc8/0x128)
>> [<c0301570>] (bad_page) from [<c03018a8>] (free_pages_prepare+0x168/0x1e0)
>> [<c03018a8>] (free_pages_prepare) from [<c030369c>] (free_hot_cold_page+0x3c/0x174)
>> [<c030369c>] (free_hot_cold_page) from [<c0303828>] (__free_pages+0x54/0x58)
>> [<c0303828>] (__free_pages) from [<c030395c>] (free_highmem_page+0x38/0x88)
>> [<c030395c>] (free_highmem_page) from [<c0f62d5c>] (mem_init+0x240/0x430)
>> [<c0f62d5c>] (mem_init) from [<c0f5db3c>] (start_kernel+0x1e4/0x3c8)
>> [<c0f5db3c>] (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?
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-01-23 0:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <54B8F63C.1060300@linaro.org>
2015-01-17 0:24 ` Issue on reserving memory with no-map flag in DT Laura Abbott
2015-01-17 8:39 ` Srinivas Kandagatla
2015-01-19 15:49 ` Vlastimil Babka
2015-01-19 23:57 ` Laura Abbott
2015-01-20 9:54 ` Vlastimil Babka
2015-01-21 1:37 ` [PATCH] mm: Don't offset memmap for flatmem Laura Abbott
2015-01-21 10:15 ` Vlastimil Babka
2015-01-22 1:01 ` [PATCHv2] " Laura Abbott
2015-01-23 0:20 ` Andrew Morton
2015-01-23 0:33 ` Laura Abbott [this message]
2015-01-23 9:05 ` Vlastimil Babka
2015-01-26 15:56 ` Mel Gorman
2015-01-29 13:13 ` Vlastimil Babka
2015-02-04 2:25 ` Laura Abbott
2015-02-24 19:54 ` Laura Abbott
2015-02-27 15:24 ` Vlastimil Babka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54C196D0.6040900@codeaurora.org \
--to=lauraa@codeaurora.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=galak@codeaurora.org \
--cc=khilman@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=linux@arm.linux.org.uk \
--cc=sboyd@codeaurora.org \
--cc=srinivas.kandagatla@linaro.org \
--cc=ssantosh@kernel.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).