linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: ignore memory outside of the linear range
Date: Mon, 17 Aug 2015 12:04:55 +0100	[thread overview]
Message-ID: <20150817110454.GC2482@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <CAKv+Gu_9zx5gZBRWO_Yg082Afoc7ksy2yJm-1xqprq06ptLJQw@mail.gmail.com>

On Mon, Aug 17, 2015 at 12:44:50PM +0200, Ard Biesheuvel wrote:
> On 17 August 2015 at 12:40, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Sat, Aug 15, 2015 at 02:13:44PM +0200, Ard Biesheuvel wrote:
> >> We need to ensure that we don't try to map system RAM ranges whose
> >> offset relative to the start of the kernel image exceeds the size of
> >> the linear range. This may happen even on systems that don't have
> >> huge amounts of RAM if it is laid out very sparsely.
> >>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> ---
> >>
> >> This is the minimal fix for addressing the issue we discussed. I dropped
> >> the other changes for now, let's revisit those when (if) my patches for
> >> decoupling the kernel mapping from the linear mapping are back under
> >> discussion.
> >>
> >> I will leave it up to the maintainers whether this constitutes a bugfix or
> >> not, but since this has never worked from the beginning afaict, I don't
> >> think it belongs in stable per se.
> >
> > Even though it is not a regression, I think it is a bug fix and it's
> > worth cc'ing stable (though we could push it after 4.3-rc1).
> >
> >> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> >> index ad87ce826cce..c65e57d4c3e7 100644
> >> --- a/arch/arm64/mm/init.c
> >> +++ b/arch/arm64/mm/init.c
> >> @@ -158,6 +158,19 @@ early_param("mem", early_mem);
> >>
> >>  void __init arm64_memblock_init(void)
> >>  {
> >> +     /*
> >> +      * Remove the memory that we will not be able to cover
> >> +      * with the linear mapping.
> >> +      */
> >> +     const s64 linear_region_size = -(s64)PAGE_OFFSET;
> >> +
> >> +     if (memstart_addr + linear_region_size < memblock_end_of_DRAM()) {
> >> +             pr_warn("Ignoring memory outside of linear range (0x%012llx - 0x%012llx)\n",
> >> +                     memstart_addr + linear_region_size,
> >> +                     (u64)memblock_end_of_DRAM() - 1);
> >> +             memblock_remove(memstart_addr + linear_region_size, ULLONG_MAX);
> >> +     }
> >
> > For memory blocks below PHYS_OFFSET, we ignore them in
> > early_init_dt_add_memory_arch() directly (and also print a warning).
> > Could we not do something similar for higher blocks? This function has a
> > check for MAX_PHYS_ADDR but thats -1ULL, so I guess the check is pretty
> > much useless. We should allow the arch code define this macro and only
> > leave the current value as default if not overridden.
> >
> 
> That is actually more or less what Mark Rutland proposed here
> 
> http://article.gmane.org/gmane.linux.ports.arm.kernel/430239

Ah, I missed this. I prefer Mark's variant more (once it's fixed).

> I proposed to override early_init_dt_add_memory_arch() completely
> instead, but Rob had some comments, after which the discussion kind of
> fizzled out.

I don't think we should override early_init_dt_add_memory_arch(), unless
we diverge too much from it. Currently, it looks to me like the end of
PA range check is pretty useless in this function.

-- 
Catalin

  reply	other threads:[~2015-08-17 11:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-15 12:13 [PATCH] arm64: ignore memory outside of the linear range Ard Biesheuvel
2015-08-17  9:43 ` Will Deacon
2015-08-17 10:35   ` Ard Biesheuvel
2015-08-17 10:53     ` Will Deacon
2015-08-17 10:55       ` Ard Biesheuvel
2015-08-17 11:11         ` Will Deacon
2015-08-17 10:40 ` Catalin Marinas
2015-08-17 10:44   ` Ard Biesheuvel
2015-08-17 11:04     ` Catalin Marinas [this message]
2015-08-17 11:06       ` Ard Biesheuvel
2015-08-17 12:07         ` Catalin Marinas

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=20150817110454.GC2482@e104818-lin.cambridge.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 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).