From: catalin.marinas@arm.com (Catalin Marinas)
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 12:15:23 +0000 [thread overview]
Message-ID: <20130206121523.GD26454@arm.com> (raw)
In-Reply-To: <510F3CA3.7080604@ti.com>
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.
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.
--
Catalin
next prev parent reply other threads:[~2013-02-06 12:15 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 [this message]
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
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=20130206121523.GD26454@arm.com \
--to=catalin.marinas@arm.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.