linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] ARM: LPAE: reduce damage caused by idmap to virtual memory layout
Date: Tue, 29 Jul 2014 11:57:17 +0100	[thread overview]
Message-ID: <20140729105717.GC30282@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CALYGNiO6PEPoHDrcLRZxQVT2=-1upyh6E-TWBCMB0MR8u5Sx6w@mail.gmail.com>

On Mon, Jul 28, 2014 at 11:57:16PM +0400, Konstantin Khlebnikov wrote:
> On Mon, Jul 28, 2014 at 11:42 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Jul 28, 2014 at 11:29:39PM +0400, Konstantin Khlebnikov wrote:
> >> Ok, before switching from identity mapping to normal mapping kernel must
> >> switch instruction pointer from physical address to virtual.
> >
> > "switch instruction pointer from physical address to virtual."
> >
> > There's no such distinction for the instruction pointer.
> 
> I know. I mean "logically".
> 
...
> 
> Sorry but I'm really look so dumb? Maybe it's true, it's almost
> midnight at my side.

When you use language which suggests a lack of understanding, then
I will explain things.

> > It doesn't matter, provided the kernel text and data in the virtual
> > address space are not overwritten by the identity mapping.  If it
> > ends up in the vmalloc or IO space, that should not be a problem.
> 
> In my case it's been overwritten.
> And it always happens when PHYS_OFFSET >= PAGE_OFFSET
> because in case of LPAE idmap always overwrites 1Gb at once.

Right, I now see what you're getting at.  Here's a better description
which I've used when committing your patch.  I've only taken patch 2
at the present time.



On LPAE, each level 1 (pgd) page table entry maps 1GiB, and the level 2
(pmd) entries map 2MiB.

When the identity mapping is created on LPAE, the pgd pointers are copied
from the swapper_pg_dir.  If we find that we need to modify the contents
of a pmd, we allocate a new empty pmd table and insert it into the
appropriate 1GB slot, before then filling it with the identity mapping.

However, if the 1GB slot covers the kernel lowmem mappings, we obliterate
those mappings.

When replacing a PMD, first copy the old PMD contents to the new PMD, so
that we preserve the existing mappings in the 1GiB region, particularly
the mappings of the kernel itself.


-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

  reply	other threads:[~2014-07-29 10:57 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-22 15:36 [PATCH 1/2] ARM: LPAE: load upper bits of early TTBR0/TTBR1 Konstantin Khlebnikov
2014-07-22 15:36 ` [PATCH 2/2] ARM: LPAE: reduce damage caused by idmap to virtual memory layout Konstantin Khlebnikov
2014-07-28 18:14   ` Will Deacon
2014-07-28 18:25     ` Konstantin Khlebnikov
2014-07-28 18:41       ` Will Deacon
2014-07-28 18:57         ` Konstantin Khlebnikov
2014-07-28 19:06           ` Will Deacon
2014-07-28 19:13           ` Russell King - ARM Linux
2014-07-28 19:29             ` Konstantin Khlebnikov
2014-07-28 19:34               ` Konstantin Khlebnikov
2014-07-28 19:42               ` Russell King - ARM Linux
2014-07-28 19:57                 ` Konstantin Khlebnikov
2014-07-29 10:57                   ` Russell King - ARM Linux [this message]
2014-07-29 12:37                     ` Konstantin Khlebnikov
2014-07-28 18:12 ` [PATCH 1/2] ARM: LPAE: load upper bits of early TTBR0/TTBR1 Will Deacon
2014-07-28 18:40   ` Konstantin Khlebnikov
2014-07-28 18:47     ` Will Deacon
2014-07-29 11:15       ` Will Deacon
2014-07-29 12:29       ` Konstantin Khlebnikov
2014-08-27 15:26         ` Jassi Brar
2014-08-27 15:31           ` Konstantin Khlebnikov
2014-08-27 15:33             ` Konstantin Khlebnikov
2014-08-27 15:45             ` Jassi Brar
2014-08-28 11:03               ` Will Deacon
2014-08-28 11:50                 ` Konstantin Khlebnikov
2014-08-05 15:42 ` Konstantin Khlebnikov

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=20140729105717.GC30282@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --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).