From: wangnan0@huawei.com (Wang Nan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: mm: fix lowmem virtual address range check
Date: Wed, 14 May 2014 18:24:12 +0800 [thread overview]
Message-ID: <5373444C.3010805@huawei.com> (raw)
In-Reply-To: <20140514101137.GC10145@arm.com>
On 2014/5/14 18:11, Will Deacon wrote:
> On Wed, May 14, 2014 at 07:03:59AM +0100, Wang Nan wrote:
>> This patch makes sure the argument of __phys_to_virt is a valid physical
>> address when clear lowmem memory maps.
>>
>> The last few lines prepare_page_table() clear page mapping in the gap
>> between largest low physical memory and the upper bound of lowmem. It
>> uses __phys_to_virt(end) to calculate virtual address from where the
>> clearing start.
>>
>> However, if the platform uses private nonliner __phys_to_virt(), 'end'
>> may goes into another mapping region.
>>
>> This patch uses __phys_to_virt(end - 1) + 1 for insurance purposes.
>>
>> Signed-off-by: Wang Nan <wangnan0@huawei.com>
>> Cc: Geng Hui <hui.geng@huawei.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> ---
>> arch/arm/mm/mmu.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
>> index b68c6b2..87340ee 100644
>> --- a/arch/arm/mm/mmu.c
>> +++ b/arch/arm/mm/mmu.c
>> @@ -1217,7 +1217,7 @@ static inline void prepare_page_table(void)
>> * Clear out all the kernel space mappings, except for the first
>> * memory bank, up to the vmalloc region.
>> */
>> - for (addr = __phys_to_virt(end);
>> + for (addr = __phys_to_virt(end - 1) + 1;
>> addr < VMALLOC_START; addr += PMD_SIZE)
>> pmd_clear(pmd_off_k(addr));
>
> This looks correct to me, but I'd be interested to know which platform this
> is falling over on. Only realview seems to override __phys_to_virt and I
> don't think we want to add more of that if we can help it.
>
> Will
>
I'm working on realview code now, trying to make it support CONFIG_ARM_PATCH_PHYS_VIRT,
and found this problem when working on its private __phys_to_virt. Realview is the only
in-kernel arm board which uses sparse memory. I think it is a good example when testing
sparse memory support of tools such as kexec-tools, kdump and crash.
next prev parent reply other threads:[~2014-05-14 10:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 6:03 [PATCH] arm: mm: fix lowmem virtual address range check Wang Nan
2014-05-14 10:11 ` Will Deacon
2014-05-14 10:24 ` Wang Nan [this message]
2014-05-14 10:39 ` Will Deacon
2014-05-14 11:31 ` Wang Nan
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=5373444C.3010805@huawei.com \
--to=wangnan0@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.