From: Philipp Rudo <prudo@redhat.com>
To: kexec@lists.infradead.org
Subject: [PATCH makedumpfile] Avoid false-positive mem_section validation with vmlinux
Date: Mon, 25 Apr 2022 11:21:22 +0200 [thread overview]
Message-ID: <20220425112122.7ef968e1@rotkaeppchen> (raw)
In-Reply-To: <TYYPR01MB6777DF79FA02B1A563395018DDF59@TYYPR01MB6777.jpnprd01.prod.outlook.com>
Hi Kazu,
On Wed, 20 Apr 2022 23:58:29 +0000
HAGIO KAZUHITO(?????) <k-hagio-ab@nec.com> wrote:
> Currently get_mem_section() validates if SYMBOL(mem_section) is the address
> of the mem_section array first. But there was a report that the first
> validation wrongly returned TRUE with -x vmlinux and SPARSEMEM_EXTREME
> (4.15+) on s390x. This leads to crash failing statup with the following
> seek error:
>
> crash: seek error: kernel virtual address: 67fffc2800 type: "memory section root table"
>
> Skip the first validation when satisfying the conditions.
>
> Reported-by: Dave Wysochanski <dwysocha@redhat.com>
> Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
for me this patch looks fine and exactly addresses the problem, that
mem_section has different types in the vmlinux and vmcoreinfo. So, for
what I want
Reviewed-and-Tested-by: Philipp Rudo <prudo@redhat.com>
> ---
> makedumpfile.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/makedumpfile.c b/makedumpfile.c
> index a2f45c84cee3..65d1c7c2f02c 100644
> --- a/makedumpfile.c
> +++ b/makedumpfile.c
> @@ -3698,6 +3698,22 @@ validate_mem_section(unsigned long *mem_sec,
> return ret;
> }
>
> +/*
> + * SYMBOL(mem_section) varies with the combination of memory model and
> + * its source:
> + *
> + * SPARSEMEM
> + * vmcoreinfo: address of mem_section root array
> + * -x vmlinux: address of mem_section root array
> + *
> + * SPARSEMEM_EXTREME v1
> + * vmcoreinfo: address of mem_section root array
> + * -x vmlinux: address of mem_section root array
> + *
> + * SPARSEMEM_EXTREME v2 (with 83e3c48729d9 and a0b1280368d1) 4.15+
> + * vmcoreinfo: address of mem_section root array
> + * -x vmlinux: address of pointer to mem_section root array
> + */
> static int
> get_mem_section(unsigned int mem_section_size, unsigned long *mem_maps,
> unsigned int num_section)
> @@ -3710,12 +3726,27 @@ get_mem_section(unsigned int mem_section_size, unsigned long *mem_maps,
> strerror(errno));
> return FALSE;
> }
> +
> + /*
> + * There was a report that the first validation wrongly returned TRUE
> + * with -x vmlinux and SPARSEMEM_EXTREME v2 on s390x, so skip it.
> + * Howerver, leave the fallback validation as it is for the -i option.
> + */
> + if (is_sparsemem_extreme() && info->name_vmlinux) {
> + unsigned long flag = 0;
> + if (get_symbol_type_name("mem_section", DWARF_INFO_GET_SYMBOL_TYPE,
> + NULL, &flag)
> + && !(flag & TYPE_ARRAY))
> + goto skip_1st_validation;
> + }
> +
> ret = validate_mem_section(mem_sec, SYMBOL(mem_section),
> mem_section_size, mem_maps, num_section);
>
> if (!ret && is_sparsemem_extreme()) {
> unsigned long mem_section_ptr;
>
> +skip_1st_validation:
> if (!readmem(VADDR, SYMBOL(mem_section), &mem_section_ptr,
> sizeof(mem_section_ptr)))
> goto out;
next prev parent reply other threads:[~2022-04-25 9:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-20 23:58 [PATCH makedumpfile] Avoid false-positive mem_section validation with vmlinux HAGIO KAZUHITO =?unknown-8bit?b?6JCp5bC+IOS4gOS7gQ==?=
2022-04-24 10:18 ` Pingfan Liu
2022-04-25 0:48 ` HAGIO KAZUHITO =?unknown-8bit?b?6JCp5bC+IOS4gOS7gQ==?=
2022-04-25 3:29 ` Pingfan Liu
2022-04-25 7:16 ` HAGIO KAZUHITO =?unknown-8bit?b?6JCp5bC+IOS4gOS7gQ==?=
2022-04-25 9:21 ` Philipp Rudo [this message]
2022-04-27 2:01 ` Pingfan Liu
2022-04-27 5:53 ` HAGIO KAZUHITO =?unknown-8bit?b?6JCp5bC+IOS4gOS7gQ==?=
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=20220425112122.7ef968e1@rotkaeppchen \
--to=prudo@redhat.com \
--cc=kexec@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