From: "HAGIO KAZUHITO(萩尾 一仁)" <k-hagio-ab@nec.com>
To: Lichen Liu <lichliu@redhat.com>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: [PATCH] makedumpfile: call initial before use cache
Date: Mon, 22 Jul 2024 06:46:09 +0000 [thread overview]
Message-ID: <072f683a-e16d-45a7-9f4c-b59e75a8d05e@nec.com> (raw)
In-Reply-To: <CAPmSd0Pd3afnTZGog3pXEY_mh093WDW27HJLUGN2QYDwk8RHyQ@mail.gmail.com>
On 2024/07/20 16:38, Lichen Liu wrote:
>> This will work only for 4.19 and later kernels, but might reduce users
>> that hit the issue. Does this work for you?
> That works for me because I'm testing for the 6.x kernel.
Thanks for the check. Is the issue a segmentation fault?
I've made a patch below, is this OK?
From 084742cba5b81da563074454ab8c879e8e411cb0 Mon Sep 17 00:00:00 2001
From: Kazuhito Hagio <k-hagio-ab@nec.com>
Date: Mon, 22 Jul 2024 14:31:43 +0900
Subject: [PATCH] Workaround for segfault by "makedumpfile --mem-usage" on PPC64
"makedumpfile --mem-usage /proc/kcore" can cause a segmentation fault on
PPC64, because the readmem() of the following code path uses cache
before it's initialized in initial().
show_mem_usage
get_page_offset
get_versiondep_info_ppc64
readmem
...
initial
cache_init
The get_page_offset() is needed to get vmcoreinfo from /proc/kcore data,
so we can avoid calling it when a vmcoreinfo exists in the ELF NOTE
segment of /proc/kcore, i.e. on Linux 4.19 and later.
(Note: for older kernels, we will need another way to fix it.)
Reported-by: Lichen Liu <lichliu@redhat.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
---
makedumpfile.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index 5b347126db76..7d1dfcca50d8 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -12019,14 +12019,14 @@ int show_mem_usage(void)
DEBUG_MSG("Read vmcoreinfo from NOTE segment: %d\n", vmcoreinfo);
}
- if (!get_page_offset())
- return FALSE;
+ if (!vmcoreinfo) {
+ if (!get_page_offset())
+ return FALSE;
- /* paddr_to_vaddr() on arm64 needs phys_base. */
- if (!get_phys_base())
- return FALSE;
+ /* paddr_to_vaddr() on arm64 needs phys_base. */
+ if (!get_phys_base())
+ return FALSE;
- if (!vmcoreinfo) {
if (!get_sys_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
return FALSE;
--
2.31.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2024-07-22 6:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-25 1:57 [PATCH] makedumpfile: call initial before use cache Lichen Liu
2024-07-17 7:44 ` HAGIO KAZUHITO(萩尾 一仁)
2024-07-20 7:38 ` Lichen Liu
2024-07-22 6:46 ` HAGIO KAZUHITO(萩尾 一仁) [this message]
2024-07-23 7:31 ` Lichen Liu
2024-07-26 0:05 ` HAGIO KAZUHITO(萩尾 一仁)
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=072f683a-e16d-45a7-9f4c-b59e75a8d05e@nec.com \
--to=k-hagio-ab@nec.com \
--cc=kexec@lists.infradead.org \
--cc=lichliu@redhat.com \
/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