Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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