All of lore.kernel.org
 help / color / mirror / Atom feed
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 15:16:38 +0000	[thread overview]
Message-ID: <20130206151638.GG26454@arm.com> (raw)
In-Reply-To: <511260FC.2090002@ti.com>

On Wed, Feb 06, 2013 at 01:56:12PM +0000, R Sricharan wrote:
> On Wednesday 06 February 2013 05:45 PM, Catalin Marinas wrote:
> > On Mon, Feb 04, 2013 at 04:44:19AM +0000, R Sricharan wrote:
> >>     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.

alloc_init_pmd() loops over pmd (similar to alloc_init_pud). If
(type->prot_sect && ((addr | next | phys) & ~SECTION_MASK) == 0) you
call a map_init_section (whatever name you think is better) function
which contains the current section code from alloc_init_section().
Something like below (easier than explaining):

static void __init map_init_section(pmd_t *pmd, unsigned long addr,
				    unsigned long end, phys_addr_t phys,
				    const struct mem_type *type)
{
#ifndef CONFIG_ARM_LPAE
	if (addr & SECTION_SIZE)
		pmd++;
#endif

	do {
		*pmd = __pmd(phys | type->prot_sect);
		phys += SECTION_SIZE;
	} while (pmd++, addr += SECTION_SIZE, addr != end);

	flush_pmd_entry(p);
}

Pretty much avoiding the indentation level in alloc_init_section() with
multiple loops.

> > 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?

Yes, you are right, the BUG_ON(pmd_bad) should catch this. The other
scenario (4K mapping followed by 1M) wouldn't be but it's relatively
safe as we don't override any entry.

-- 
Catalin

  reply	other threads:[~2013-02-06 15:16 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
2013-02-06 15:16                   ` Catalin Marinas [this message]
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=20130206151638.GG26454@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.