From: Baoquan He <bhe@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org, x86@kernel.org,
Baoquan He <bhe@redhat.com>,
arnd@arndb.de, ignat@cloudflare.com, kexec@lists.infradead.org,
viro@zeniv.linux.org.uk, eric_devolder@yahoo.com,
linux-fsdevel@vger.kernel.org, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
hbathini@linux.ibm.com, ebiederm@xmission.com
Subject: [PATCH 4/5] crash: remove dependency of FA_DUMP on CRASH_DUMP
Date: Fri, 5 Jan 2024 18:33:04 +0800 [thread overview]
Message-ID: <20240105103305.557273-5-bhe@redhat.com> (raw)
In-Reply-To: <20240105103305.557273-1-bhe@redhat.com>
In kdump kernel, /proc/vmcore is an elf file which maps the crashed kernel's
read_from_oldmemmemory content. Its elf header is constructed in 1st kernel and passed
to kdump kernel via elfcorehdr_addr. Config CRASH_DUMP enables the code
of 1st kernel's old memory accessing in different architectures.
Currently, config FA_DUMP has dependency on CRASH_DUMP because fadump
needs access global variable 'elfcorehdr_addr' to judge if it's in
kdump kernel within function is_kdump_kernel(). In kernel/crash_dump.c,
variable 'elfcorehdr_addr' is defined, and function setup_elfcorehdr()
is used to parse kernel parameter 'elfcorehdr' to fetch the passed
value of elfcorehdr_addr. With the need of accessing elfcorehdr_addr,
FA_DUMP doesn't have to depends on CRASH_DUMP.
To remove the dependency of FA_DUMP on CRASH_DUMP to avoid confusion,
rename kernel/crash_dump.c to kernel/elfcorehdr.c, and build it when
CONFIG_VMCORE_INFO is ebabled. With this, FA_DUMP doesn't need to depend
on CRASH_DUMP.
In file included from kernel/vmcore_info.c:25:
kernel/kexec_internal.h:11:54: warning: ‘struct kexec_segment’ declared inside parameter list will not be visible outside of this definition or declaration
11 | int kimage_load_segment(struct kimage *image, struct kexec_segment *segment);
| ^~~~~~~~~~~~~
Signed-off-by: Baoquan He <bhe@redhat.com>
---
arch/powerpc/Kconfig | 1 -
kernel/Makefile | 3 +--
kernel/{crash_dump.c => elfcorehdr.c} | 0
kernel/kexec_internal.h | 2 ++
4 files changed, 3 insertions(+), 3 deletions(-)
rename kernel/{crash_dump.c => elfcorehdr.c} (100%)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index d391e8cddf6c..22a04891c68d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -691,7 +691,6 @@ config FA_DUMP
depends on PPC64 && (PPC_RTAS || PPC_POWERNV)
select VMCORE_INFO
select CRASH_RESERVE
- select CRASH_DUMP
help
A robust mechanism to get reliable kernel crash dump with
assistance from firmware. This approach does not use kexec,
diff --git a/kernel/Makefile b/kernel/Makefile
index 08980e5c2080..25ac9345ef79 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -68,7 +68,7 @@ obj-$(CONFIG_MODULE_SIG_FORMAT) += module_signature.o
obj-$(CONFIG_KALLSYMS) += kallsyms.o
obj-$(CONFIG_KALLSYMS_SELFTEST) += kallsyms_selftest.o
obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
-obj-$(CONFIG_VMCORE_INFO) += vmcore_info.o
+obj-$(CONFIG_VMCORE_INFO) += vmcore_info.o elfcorehdr.o
obj-$(CONFIG_CRASH_RESERVE) += crash_reserve.o
obj-$(CONFIG_KEXEC_CORE) += kexec_core.o
obj-$(CONFIG_KEXEC) += kexec.o
@@ -120,7 +120,6 @@ obj-$(CONFIG_PERF_EVENTS) += events/
obj-$(CONFIG_USER_RETURN_NOTIFIER) += user-return-notifier.o
obj-$(CONFIG_PADATA) += padata.o
-obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-$(CONFIG_JUMP_LABEL) += jump_label.o
obj-$(CONFIG_CONTEXT_TRACKING) += context_tracking.o
obj-$(CONFIG_TORTURE_TEST) += torture.o
diff --git a/kernel/crash_dump.c b/kernel/elfcorehdr.c
similarity index 100%
rename from kernel/crash_dump.c
rename to kernel/elfcorehdr.c
diff --git a/kernel/kexec_internal.h b/kernel/kexec_internal.h
index 74da1409cd14..2595defe8c0d 100644
--- a/kernel/kexec_internal.h
+++ b/kernel/kexec_internal.h
@@ -4,6 +4,8 @@
#include <linux/kexec.h>
+struct kexec_segment;
+
struct kimage *do_kimage_alloc_init(void);
int sanity_check_segment_list(struct kimage *image);
void kimage_free_page_list(struct list_head *list);
--
2.41.0
next prev parent reply other threads:[~2024-01-05 10:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-05 10:33 [PATCH 0/5] crash: clean up kdump related config items Baoquan He
2024-01-05 10:33 ` [PATCH 1/5] kexec_core: move kdump related codes from crash_core.c to kexec_core.c Baoquan He
2024-01-06 10:59 ` kernel test robot
2024-01-07 13:58 ` Baoquan He
2024-01-06 14:58 ` kernel test robot
2024-01-07 8:52 ` Baoquan He
2024-01-05 10:33 ` [PATCH 2/5] kexec: split crashkernel reservation code out from crash_core.c Baoquan He
2024-01-05 10:33 ` [PATCH 3/5] crash: rename crash_core to vmcore_info Baoquan He
2024-01-05 10:33 ` Baoquan He [this message]
2024-01-05 10:33 ` [PATCH 5/5] crash: clean up CRASH_DUMP Baoquan He
2024-01-07 13:19 ` kernel test robot
2024-01-09 3:49 ` Baoquan He
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=20240105103305.557273-5-bhe@redhat.com \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=ebiederm@xmission.com \
--cc=eric_devolder@yahoo.com \
--cc=hbathini@linux.ibm.com \
--cc=ignat@cloudflare.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=viro@zeniv.linux.org.uk \
--cc=x86@kernel.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).