From: r.sricharan@ti.com (R Sricharan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4] ARM: LPAE: Fix mapping in alloc_init_pte for unaligned addresses
Date: Wed, 6 Feb 2013 19:26:12 +0530 [thread overview]
Message-ID: <511260FC.2090002@ti.com> (raw)
In-Reply-To: <20130206121523.GD26454@arm.com>
On Wednesday 06 February 2013 05:45 PM, Catalin Marinas wrote:
> On Mon, Feb 04, 2013 at 04:44:19AM +0000, R Sricharan wrote:
>> On Monday 04 February 2013 10:10 AM, R Sricharan wrote:
>>>> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
>>>> index 9f06102..47154f3 100644
>>>> --- a/arch/arm/mm/mmu.c
>>>> +++ b/arch/arm/mm/mmu.c
>>>> @@ -581,34 +581,36 @@ static void __init alloc_init_section(pud_t
>>>> *pud, unsigned long addr,
>>>> const struct mem_type *type)
>>>> {
>>>> pmd_t *pmd = pmd_offset(pud, addr);
>>>> + unsigned long next;
>>>>
>>>> - /*
>>>> - * Try a section mapping - end, addr and phys must all be aligned
>>>> - * to a section boundary. Note that PMDs refer to the individual
>>>> - * L1 entries, whereas PGDs refer to a group of L1 entries making
>>>> - * up one logical pointer to an L2 table.
>>>> - */
>>>> - if (type->prot_sect && ((addr | end | phys) & ~SECTION_MASK) == 0) {
>>>> - pmd_t *p = pmd;
>>>> + do {
>>>> + next = pmd_addr_end(addr, end);
>>>> +
>>>> + /*
>>>> + * Try a section mapping - next, addr and phys must all be
>>>> + * aligned to a section boundary. Note that PMDs refer to the
>>>> + * individual L1 entries, whereas PGDs refer to a group of L1
>>>> + * entries making up one logical pointer to an L2 table.
>>>> + */
>>>> + if (((addr | next | phys) & ~SECTION_MASK) == 0) {
>>>> + pmd_t *p = pmd;
>>>>
>>> There is a need to do page mappings even when all the addresses
>>> are aligned. This was added with CMA, which required the initial
>>> mappings to be set with 2 level tables.
>>>
>> Sorry, i wanted to ask type->prot_sect is removed here and is that
>> intentional?
>
> No, I just forgot about it.
>
>> I did a similar kind of patch in my V1 [1].
>> I should be using PMD_MASK instead of SECTION_MASK there, and
>> updated it in the next version.
>>
>> [1] https://patchwork.kernel.org/patch/1272991/
>
> With regards to your current patch, I really don't think looping over
> pmd in alloc_init_pte() is the right fix. The alloc_init_pte() function
> gets a pmd argument and it is supposed to make it point to a pte and
> populate that pte rather than populate a number of pmds.
>
> create_mapping() loops over pgds. alloc_init_pud() loops over puds
> (well, we don't have any but we have the function for consistency).
> alloc_init_section() should loop over pmds (we can even change the name
> to alloc_init_pmd()).
>
> Your original patch from August was better as it kept the looping
> consistent but as you said, it should be using pmd_addr_end(). We can
> use something simpler like alloc_init_pmd() on arm64 and instead of
> set_pmd() there just call a separate map_init_section() which for
> 2-levels it sets both entries. This may address Russell's comment that
> the resulting code was ugly.
Thanks. So just to understand, you mean alloc_init_pmd loops over
map_init_section. map_init_section populates either one pmd
or calls alloc_init_pte. correct ? . I can send a v5 for this.
>
> The problem with the classic MMU is that if we have a 1MB range we can
> end up with just page mappings. The code is currently buggy since if we
> have create_mapping() for a 1MB range and later create_mapping() for a
> 4KB in the next MB, the first 1MB is removed.
>
Ok, so in that case we will have a BUG_ON(pmd_bad) right?
Earlier we had this hit when both static and page mappings
were attempted in the same 2MB range and understood it was wrong.
Regards,
Sricharan
next prev parent reply other threads:[~2013-02-06 13:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-29 15:07 [PATCH v4] ARM: LPAE: Fix mapping in alloc_init_pte for unaligned addresses R Sricharan
2013-02-01 6:21 ` Santosh Shilimkar
2013-02-01 16:26 ` Catalin Marinas
2013-02-01 16:32 ` Christoffer Dall
2013-02-01 16:37 ` Catalin Marinas
2013-02-01 16:40 ` Christoffer Dall
2013-02-01 17:42 ` Catalin Marinas
2013-02-01 18:37 ` Christoffer Dall
2013-02-04 4:40 ` R Sricharan
2013-02-04 4:44 ` R Sricharan
2013-02-04 11:10 ` R Sricharan
2013-02-06 12:15 ` Catalin Marinas
2013-02-06 12:22 ` Russell King - ARM Linux
2013-02-06 12:33 ` Catalin Marinas
2013-02-06 13:59 ` R Sricharan
2013-02-06 13:56 ` R Sricharan [this message]
2013-02-06 15:16 ` Catalin Marinas
2013-02-06 15:25 ` R Sricharan
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=511260FC.2090002@ti.com \
--to=r.sricharan@ti.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 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).