All of lore.kernel.org
 help / color / mirror / Atom feed
From: james.morse@arm.com (James Morse)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: mark reserved memblock regions explicitly in iomem
Date: Thu, 25 Aug 2016 16:27:47 +0100	[thread overview]
Message-ID: <57BF0E73.7060801@arm.com> (raw)
In-Reply-To: <20160822065524.8085-1-takahiro.akashi@linaro.org>

Hi Akashi,

On 22/08/16 07:55, AKASHI Takahiro wrote:
> Kdump(kexec-tools) parses /proc/iomem to identify all the memory regions
> on the system. Since the current kernel names "nomap" regions, like UEFI
> runtime services code/data, as "System RAM," kexec-tools sets up elf core
> header to include them in a crash dump file (/proc/vmcore).
> 
> Then crash dump kernel parses UEFI memory map again, re-marks those regions
> as "nomap" and does not create a memory mapping for them unlike the other
> areas of System RAM. In this case, copying /proc/vmcore through
> copy_oldmem_page() on crash dump kernel will end up with a kernel abort,
> as reported in [1].
> 
> This patch names all the "nomap" regions explicitly as "reserved" so that
> we can exclude them from a crash dump file. acpi_os_ioremap() must also
> be modified because those regions have WB attributes [2].
> 
> Apart from kdump, this change also matches x86's use of acpi (and
> /proc/iomem).
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/448186.html
> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/450089.html


Tested on Seattle on v4.8-rc3, /proc/iomem Before:
8000000000-8001e7ffff : System RAM
8001e80000-83ff186fff : System RAM
  8002080000-8002baffff : Kernel code
  8002ca0000-8002db1fff : Kernel data
83ff187000-83ff1c4fff : System RAM
83ff1c5000-83ff224fff : System RAM
83ff225000-83ffe42fff : System RAM
83ffe43000-83ffffffff : System RAM

/proc/iomem After:
8000000000-8001e7ffff : reserved
8001e80000-83ff186fff : System RAM
  8002080000-8002baffff : Kernel code
  8002ca0000-8002db1fff : Kernel data
83ff187000-83ff1c4fff : reserved
83ff1c5000-83ff224fff : System RAM
83ff225000-83ffe42fff : reserved
83ffe43000-83ffffffff : System RAM

Which matches the output from 'efi=debug'.

I can also kdump with v24 of your series, and copy the vmcore file with
read()/mmap() and dig through it with crash.

Tested-by: James Morse <james.morse@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>


The only side-effect of this I could find is we now allow access to the UEFI
areas when built with CONFIG_STRICT_DEVMEM, which is what the help text says
should happen, so it was broken before.



Thanks,

James

      parent reply	other threads:[~2016-08-25 15:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-22  6:55 [PATCH] arm64: mark reserved memblock regions explicitly in iomem AKASHI Takahiro
2016-08-25 14:25 ` Catalin Marinas
2016-08-25 15:27 ` James Morse [this message]

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=57BF0E73.7060801@arm.com \
    --to=james.morse@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.