linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v31 09/12] arm64: kdump: provide /proc/vmcore file
Date: Thu, 2 Feb 2017 15:24:09 +0900	[thread overview]
Message-ID: <20170202062408.GC13549@linaro.org> (raw)
In-Reply-To: <20170201192121.GB30584@leverpostej>

On Wed, Feb 01, 2017 at 07:21:22PM +0000, Mark Rutland wrote:
> On Wed, Feb 01, 2017 at 09:46:28PM +0900, AKASHI Takahiro wrote:
> > Add arch-specific functions to provide a dump file, /proc/vmcore.
> > 
> > This file is in ELF format and its ELF header needs to be prepared by
> > userspace tools, like kexec-tools, in adance. The primary kernel is
> > responsible to allocate the region with reserve_elfcorehdr() at boot time
> > and advertize its location to crash dump kernel via a new device-tree
> > property, "linux,elfcorehdr".
> 
> > +static int __init early_init_dt_scan_elfcorehdr(unsigned long node,
> > +		const char *uname, int depth, void *data)
> > +{
> > +	const __be32 *reg;
> > +	int len;
> > +
> > +	if (depth != 1 || strcmp(uname, "chosen") != 0)
> > +		return 0;
> > +
> > +	reg = of_get_flat_dt_prop(node, "linux,elfcorehdr", &len);
> > +	if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
> > +		return 1;
> > +
> > +	elfcorehdr_addr = dt_mem_next_cell(dt_root_addr_cells, &reg);
> > +	elfcorehdr_size = dt_mem_next_cell(dt_root_size_cells, &reg);
> > +
> > +	return 1;
> > +}
> > +
> > +/*
> > + * reserve_elfcorehdr() - reserves memory for elf core header
> > + *
> > + * This function reserves elf core header given in "elfcorehdr=" kernel
> > + * command line parameter. This region contains all the information about
> > + * primary kernel's core image and is used by a dump capture kernel to
> > + * access the system memory on primary kernel.
> > + */
> > +static void __init reserve_elfcorehdr(void)
> > +{
> > +	of_scan_flat_dt(early_init_dt_scan_elfcorehdr, NULL);
> > +
> > +	if (!elfcorehdr_size)
> > +		return;
> > +
> > +	if (memblock_is_region_reserved(elfcorehdr_addr, elfcorehdr_size)) {
> > +		pr_warn("elfcorehdr is overlapped\n");
> > +		return;
> > +	}
> > +
> > +	memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > +
> > +	pr_info("Reserving %lldKB of memory at 0x%llx for elfcorehdr\n",
> > +		elfcorehdr_size >> 10, elfcorehdr_addr);
> > +}
> 
> This doesn't seem right to me.  The logic here doesn't match the commit
> message, the comment above reserve_elfcorehdr() doesn't match the
> implementation, and this doesn't match my understanding of how this was
> intended to be used from the DT binding.

Surely the commit message was wrong/misleading; It should say

===8<===
Arch-specific functions are added to allow for implementing a crash dump
file interface, /proc/vmcore, which can be viewed as a ELF file.

A user space tool, like kexec-tools, is responsible for allocating
a separate region for the core's ELF header within crash kdump kernel 
memory and filling it in when executing kexec_load().

Then, its location will be advertised to crash dump kernel via a new
device-tree property, "linux,elfcorehdr", and crash dump kernel preserves
the region for later use with reserve_elfcorehdr()@boot time.

On crash dump kernel, /proc/vmcore will access the primary kernel's memory
with copy_oldmem_page(), which feeds the data page-by-page by ioremap'ing
it since it does not reside in linear mapping on crash dump kernel.

Meanwhile, elfcorehdr_read() is simple as the region is always mapped.
===>8===

Does this make things clear?

> I had assumed that we'd treat this in much the same way as the
> linux,reserved-memory-region property, with the primary kernel either
> dynamically allocating the region or using a command line option, and
> the base being exposed to userspace via /sys/ or /proc/ somehow.

I didn't get the point here, but please note that the data in ELF core header
is produced by kexec-tools (who knows its location, too), and consumed solely
by the crash dump kernel.

Thanks,
-Takahiro AKASHI

> Why is that not the case?
> 
> Thanks,
> Mark.

  reply	other threads:[~2017-02-02  6:24 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-01 12:42 [PATCH v31 00/12] add kdump support AKASHI Takahiro
2017-02-01 12:45 ` [PATCH v31 01/12] memblock: add memblock_cap_memory_range() AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 02/12] arm64: limit memory regions based on DT property, usable-memory-range AKASHI Takahiro
2017-02-01 15:07   ` Mark Rutland
2017-02-02  4:21     ` AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 03/12] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2017-02-01 15:26   ` Mark Rutland
2017-02-02  4:52     ` AKASHI Takahiro
2017-02-02 11:26       ` Mark Rutland
2017-02-02 13:44         ` AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 04/12] arm64: mm: allow for unmapping part of kernel mapping AKASHI Takahiro
2017-02-01 16:03   ` Mark Rutland
2017-02-02 10:21     ` AKASHI Takahiro
2017-02-02 11:44       ` Mark Rutland
2017-02-02 14:01         ` AKASHI Takahiro
2017-02-02 14:35           ` Mark Rutland
2017-02-02 14:55             ` AKASHI Takahiro
2017-02-03  6:13               ` AKASHI Takahiro
2017-02-03 14:22                 ` Mark Rutland
2017-02-01 12:46 ` [PATCH v31 05/12] arm64: kdump: protect crash dump kernel memory AKASHI Takahiro
2017-02-01 18:00   ` Mark Rutland
2017-02-01 18:25     ` Mark Rutland
2017-02-02 10:39       ` AKASHI Takahiro
2017-02-02 11:54         ` Mark Rutland
2017-02-03  1:45           ` AKASHI Takahiro
2017-02-03 11:51             ` Mark Rutland
2017-02-02 10:45       ` James Morse
2017-02-02 11:19         ` AKASHI Takahiro
2017-02-02 11:48         ` Mark Rutland
2017-02-02 10:31     ` AKASHI Takahiro
2017-02-02 11:16       ` Mark Rutland
2017-02-02 14:36         ` AKASHI Takahiro
2017-02-02 15:36           ` Mark Rutland
2017-02-01 12:46 ` [PATCH v31 06/12] arm64: hibernate: preserve kdump image around hibernation AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 07/12] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 08/12] arm64: kdump: add VMCOREINFO's for user-space tools AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 09/12] arm64: kdump: provide /proc/vmcore file AKASHI Takahiro
2017-02-01 19:21   ` Mark Rutland
2017-02-02  6:24     ` AKASHI Takahiro [this message]
2017-02-02 12:03       ` Mark Rutland
2017-02-02 12:08         ` Mark Rutland
2017-02-02 14:39           ` AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 10/12] arm64: kdump: enable kdump in defconfig AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 11/12] Documentation: kdump: describe arm64 port AKASHI Takahiro
2017-02-01 12:48 ` [PATCH v31 12/12] Documentation: dt: chosen properties for arm64 kdump AKASHI Takahiro

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=20170202062408.GC13549@linaro.org \
    --to=takahiro.akashi@linaro.org \
    --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).