Re: kexec does not work for kernel version with patch level >= 256
On 03/31/21 at 11:04am, Patrick Sung wrote:
> On Wed, Mar 31, 2021 at 10:47 AM Baoquan He wrote:
> >
> > On 03/24/21 at 12:28pm, Patrick Sung wrote:
> > > Hello all,
> > >
> > > I am using the 4.9 long term kernel which is currently at 4.9.262.
> > > When using this kernel with kexec-tools it prints out this error
> > >
> > > Unsupported utsname.release: 4.9.262
> > > Cannot load
> > >
> > > A quick search in the code shows that kexec/kernel_version.c doing this
> > > check:
> > >
> > > if (major >= 256 || minor >= 256 || patch >= 256) {
> > >
> > > and also in kexec/kexec.h
> > > #define KERNEL_VERSION(major, minor, patch) \
> > > (((major) << 16) | ((minor) << 8) | patch)
> >
> > Yeah, this seems to be a good catch. The existing longterm kenrel 4.9.262
> > does cause the problem. I am not very sure about the longterm kernel
> > version numbering, maybe we can leave 16 bits for for patch number to
> > avoid the longterm kernel issue?
> >
> > Is there document telling the longterm kernel version numbering, or any
> > pointer?
> >
> Actually I found that the mainline kernel clamp the "patch" version to 255
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?id=9b82f13e7ef316cdc0a8858f1349f4defce3f9e0
Yeah, mainline kernel use below formula to construct kernel version.
Seems longterm kernel takes a different way. While it's understandable
that Longterm kernel using a larger patch number since it will evolve
evolve for a longer time to get in bug fixes. Maybe we should enlarge
patch number to 16 bits?
echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + \
((c) > 255 ? 255 : (c)))';
By the way, it calls 'a' version number, 'b' patch level, 'c' sub-level
in Makefile of kernel?
>
> > Thanks
> > Baoquan
> >
> > >
> > > which explains the reason for the range check in kernel_version.c
> > >
> > > Increasing the number of bits allowed in "patch" seems to fix the issue.
> > >
> > > Thanks,
> > > Patrick
> > >
> > > ___
> > > kexec mailing list
> > > kexec@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/kexec
> > >
> >
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v3 00/12] Add build ID to stacktraces
This series adds the kernel's build ID[1] to the stacktrace header printed in oops messages, warnings, etc. and the build ID for any module that appears in the stacktrace after the module name. The goal is to make the stacktrace more self-contained and descriptive by including the relevant build IDs in the kernel logs when something goes wrong. This can be used by post processing tools like script/decode_stacktrace.sh and kernel developers to easily locate the debug info associated with a kernel crash and line up what line and file things started falling apart at. To show how this can be used I've included a patch to decode_stacktrace.sh that downloads the debuginfo from a debuginfod server. This also includes some patches to make the buildid.c file use more const arguments and consolidate logic into buildid.c from kdump. These are left to the end as they were mostly cleanup patches. I don't know who exactly maintains this so I guess Andrew is the best option to merge all this code. Here's an example lkdtm stacktrace on arm64. WARNING: CPU: 4 PID: 3255 at drivers/misc/lkdtm/bugs.c:83 lkdtm_WARNING+0x28/0x30 [lkdtm] Modules linked in: lkdtm rfcomm algif_hash algif_skcipher af_alg xt_cgroup uinput xt_MASQUERADE CPU: 4 PID: 3255 Comm: bash Not tainted 5.11 #3 aa23f7a1231c229de205662d5a9e0d4c580f19a1 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) pstate: 0049 (nzcv daif +PAN -UAO -TCO BTYPE=--) pc : lkdtm_WARNING+0x28/0x30 [lkdtm] lr : lkdtm_do_action+0x24/0x40 [lkdtm] sp : ffc0134fbca0 x29: ffc0134fbca0 x28: ff92d53ba240 x27: x26: x25: x24: ffe3622352c0 x23: 0020 x22: ffe362233366 x21: ffe3622352e0 x20: ffc0134fbde0 x19: 0008 x18: x17: ff929b6536fc x16: x15: x14: 0012 x13: ffe380ed892c x12: ffe381d05068 x11: x10: x9 : 0001 x8 : ffe362237000 x7 : x6 : x5 : x4 : 0001 x3 : 0008 x2 : ff93fef25a70 x1 : ff93fef15788 x0 : ffe3622352e0 Call trace: lkdtm_WARNING+0x28/0x30 [lkdtm ed5019fdf5e53be37cb1ba7899292d7e143b259e] direct_entry+0x16c/0x1b4 [lkdtm ed5019fdf5e53be37cb1ba7899292d7e143b259e] full_proxy_write+0x74/0xa4 vfs_write+0xec/0x2e8 ksys_write+0x84/0xf0 __arm64_sys_write+0x24/0x30 el0_svc_common+0xf4/0x1c0 do_el0_svc_compat+0x28/0x3c el0_svc_compat+0x10/0x1c el0_sync_compat_handler+0xa8/0xcc el0_sync_compat+0x178/0x180 ---[ end trace 3d95032303e59e68 ]--- Changes from v2 (https://lore.kernel.org/r/20210324020443.1815557-1-swb...@chromium.org): * Renamed symbol printing function to indicate build IDness * Put build ID information behind Kconfig knob * Build ID for vmlinux is calculated in early init instead of on demand * printk format is %pS[R]b Changes from v1 (https://lore.kernel.org/r/20210301174749.1269154-1-swb...@chromium.org): * New printk format %pSb and %pSr * Return binary format instead of hex format string from build ID APIs * Some new patches to cleanup buildid/decode_stacktrace.sh * A new patch to decode_stacktrace.sh to parse output [1] https://fedoraproject.org/wiki/Releases/FeatureBuildId Cc: Alexei Starovoitov Cc: Andy Shevchenko Cc: Baoquan He Cc: Borislav Petkov Cc: Catalin Marinas Cc: Dave Young Cc: Evan Green Cc: Hsin-Yi Wang Cc: Ingo Molnar Cc: Jessica Yu Cc: Jiri Olsa Cc: Cc: Konstantin Khlebnikov Cc: Cc: Cc: Cc: Matthew Wilcox Cc: Petr Mladek Cc: Rasmus Villemoes Cc: Sasha Levin Cc: Sergey Senozhatsky Cc: Steven Rostedt Cc: Thomas Gleixner Cc: Vivek Goyal Cc: Will Deacon Cc: Cc: Christoph Hellwig Cc: peter enderborg Stephen Boyd (12): buildid: Add API to parse build ID out of buffer buildid: Stash away kernels build ID on init dump_stack: Add vmlinux build ID to stack traces module: Add printk format to add module build ID to stacktraces arm64: stacktrace: Use %pSb for backtrace printing x86/dumpstack: Use %pSb for backtrace printing scripts/decode_stacktrace.sh: Support debuginfod scripts/decode_stacktrace.sh: Silence stderr messages from addr2line/nm scripts/decode_stacktrace.sh: Indicate 'auto' can be used for base path buildid: Mark some arguments const buildid: Fix kernel-doc notation kdump: Use vmlinux_build_id to simplify Documentation/core-api/printk-formats.rst | 9 +++ arch/arm64/kernel/stacktrace.c| 2 +- arch/x86/kernel/dumpstack.c | 4 +- include/linux/buildid.h | 4 + include/linux/crash_core.h| 6 +- include/linux/kallsyms.h | 13 +++- include/linux/module.h| 6 +- init/main.c | 1 + kernel/crash_core.c | 41 +-- kernel/kallsyms.c | 7
[PATCH v3 12/12] kdump: Use vmlinux_build_id to simplify
We can use the vmlinux_build_id array here now instead of open coding
it. This mostly consolidates code.
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Cc: Dave Young
Cc: Baoquan He
Cc: Vivek Goyal
Cc:
Signed-off-by: Stephen Boyd
---
include/linux/crash_core.h | 6 +-
kernel/crash_core.c| 41 ++
2 files changed, 3 insertions(+), 44 deletions(-)
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index 206bde8308b2..fb8ab99bb2ee 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -39,7 +39,7 @@ phys_addr_t paddr_vmcoreinfo_note(void);
#define VMCOREINFO_OSRELEASE(value) \
vmcoreinfo_append_str("OSRELEASE=%s\n", value)
#define VMCOREINFO_BUILD_ID(value) \
- vmcoreinfo_append_str("BUILD-ID=%s\n", value)
+ vmcoreinfo_append_str("BUILD-ID=%20phN\n", value)
#define VMCOREINFO_PAGESIZE(value) \
vmcoreinfo_append_str("PAGESIZE=%ld\n", value)
#define VMCOREINFO_SYMBOL(name) \
@@ -69,10 +69,6 @@ extern unsigned char *vmcoreinfo_data;
extern size_t vmcoreinfo_size;
extern u32 *vmcoreinfo_note;
-/* raw contents of kernel .notes section */
-extern const void __start_notes __weak;
-extern const void __stop_notes __weak;
-
Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
void *data, size_t data_len);
void final_note(Elf_Word *buf);
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 825284baaf46..6b560cf9f374 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -4,6 +4,7 @@
* Copyright (C) 2002-2004 Eric Biederman
*/
+#include
#include
#include
#include
@@ -378,51 +379,13 @@ phys_addr_t __weak paddr_vmcoreinfo_note(void)
}
EXPORT_SYMBOL(paddr_vmcoreinfo_note);
-#define NOTES_SIZE (&__stop_notes - &__start_notes)
-#define BUILD_ID_MAX SHA1_DIGEST_SIZE
-#define NT_GNU_BUILD_ID 3
-
-struct elf_note_section {
- struct elf_note n_hdr;
- u8 n_data[];
-};
-
/*
* Add build ID from .notes section as generated by the GNU ld(1)
* or LLVM lld(1) --build-id option.
*/
static void add_build_id_vmcoreinfo(void)
{
- char build_id[BUILD_ID_MAX * 2 + 1];
- int n_remain = NOTES_SIZE;
-
- while (n_remain >= sizeof(struct elf_note)) {
- const struct elf_note_section *note_sec =
- &__start_notes + NOTES_SIZE - n_remain;
- const u32 n_namesz = note_sec->n_hdr.n_namesz;
-
- if (note_sec->n_hdr.n_type == NT_GNU_BUILD_ID &&
- n_namesz != 0 &&
- !strcmp((char *)¬e_sec->n_data[0], "GNU")) {
- if (note_sec->n_hdr.n_descsz <= BUILD_ID_MAX) {
- const u32 n_descsz = note_sec->n_hdr.n_descsz;
- const u8 *s = ¬e_sec->n_data[n_namesz];
-
- s = PTR_ALIGN(s, 4);
- bin2hex(build_id, s, n_descsz);
- build_id[2 * n_descsz] = '\0';
- VMCOREINFO_BUILD_ID(build_id);
- return;
- }
- pr_warn("Build ID is too large to include in
vmcoreinfo: %u > %u\n",
- note_sec->n_hdr.n_descsz,
- BUILD_ID_MAX);
- return;
- }
- n_remain -= sizeof(struct elf_note) +
- ALIGN(note_sec->n_hdr.n_namesz, 4) +
- ALIGN(note_sec->n_hdr.n_descsz, 4);
- }
+ VMCOREINFO_BUILD_ID(vmlinux_build_id);
}
static int __init crash_save_vmcoreinfo_init(void)
--
https://chromeos.dev
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec does not work for kernel version with patch level >= 256
On Wed, Mar 31, 2021 at 10:47 AM Baoquan He wrote:
>
> On 03/24/21 at 12:28pm, Patrick Sung wrote:
> > Hello all,
> >
> > I am using the 4.9 long term kernel which is currently at 4.9.262.
> > When using this kernel with kexec-tools it prints out this error
> >
> > Unsupported utsname.release: 4.9.262
> > Cannot load
> >
> > A quick search in the code shows that kexec/kernel_version.c doing this
> > check:
> >
> > if (major >= 256 || minor >= 256 || patch >= 256) {
> >
> > and also in kexec/kexec.h
> > #define KERNEL_VERSION(major, minor, patch) \
> > (((major) << 16) | ((minor) << 8) | patch)
>
> Yeah, this seems to be a good catch. The existing longterm kenrel 4.9.262
> does cause the problem. I am not very sure about the longterm kernel
> version numbering, maybe we can leave 16 bits for for patch number to
> avoid the longterm kernel issue?
>
> Is there document telling the longterm kernel version numbering, or any
> pointer?
>
Actually I found that the mainline kernel clamp the "patch" version to 255
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?id=9b82f13e7ef316cdc0a8858f1349f4defce3f9e0
> Thanks
> Baoquan
>
> >
> > which explains the reason for the range check in kernel_version.c
> >
> > Increasing the number of bits allowed in "patch" seems to fix the issue.
> >
> > Thanks,
> > Patrick
> >
> > ___
> > kexec mailing list
> > kexec@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
> >
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v3 02/12] buildid: Stash away kernels build ID on init
Parse the kernel's build ID at initialization so that other code can
print a hex format string representation of the running kernel's build
ID. This will be used in the kdump and dump_stack code so that
developers can easily locate the vmlinux debug symbols for a
crash/stacktrace.
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Cc: Jessica Yu
Cc: Evan Green
Cc: Hsin-Yi Wang
Cc: Dave Young
Cc: Baoquan He
Cc: Vivek Goyal
Cc:
Signed-off-by: Stephen Boyd
---
include/linux/buildid.h | 3 +++
init/main.c | 1 +
lib/buildid.c | 17 +
3 files changed, 21 insertions(+)
diff --git a/include/linux/buildid.h b/include/linux/buildid.h
index ebce93f26d06..0312660089c3 100644
--- a/include/linux/buildid.h
+++ b/include/linux/buildid.h
@@ -10,4 +10,7 @@ int build_id_parse(struct vm_area_struct *vma, unsigned char
*build_id,
__u32 *size);
int build_id_parse_buf(const void *buf, unsigned char *build_id, u32 buf_size);
+extern unsigned char vmlinux_build_id[];
+void init_vmlinux_build_id(void);
+
#endif
diff --git a/init/main.c b/init/main.c
index 53b278845b88..eaede2f41327 100644
--- a/init/main.c
+++ b/init/main.c
@@ -857,6 +857,7 @@ asmlinkage __visible void __init __no_sanitize_address
start_kernel(void)
set_task_stack_end_magic(&init_task);
smp_setup_processor_id();
debug_objects_early_init();
+ init_vmlinux_build_id();
cgroup_init_early();
diff --git a/lib/buildid.c b/lib/buildid.c
index 010ab0674cb9..b939bbc59233 100644
--- a/lib/buildid.c
+++ b/lib/buildid.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#include
+#include
#include
#include
#include
@@ -171,3 +172,19 @@ int build_id_parse_buf(const void *buf, unsigned char
*build_id, u32 buf_size)
{
return parse_build_id_buf(build_id, NULL, buf, buf_size);
}
+
+unsigned char vmlinux_build_id[BUILD_ID_SIZE_MAX] __ro_after_init;
+
+/**
+ * init_vmlinux_build_id - Get the running kernel's build ID
+ *
+ * Return: Running kernel's build ID
+ */
+void __init init_vmlinux_build_id(void)
+{
+ extern const void __start_notes __weak;
+ extern const void __stop_notes __weak;
+ unsigned int size = &__stop_notes - &__start_notes;
+
+ build_id_parse_buf(&__start_notes, vmlinux_build_id, size);
+}
--
https://chromeos.dev
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: kexec does not work for kernel version with patch level >= 256
On 03/24/21 at 12:28pm, Patrick Sung wrote:
> Hello all,
>
> I am using the 4.9 long term kernel which is currently at 4.9.262.
> When using this kernel with kexec-tools it prints out this error
>
> Unsupported utsname.release: 4.9.262
> Cannot load
>
> A quick search in the code shows that kexec/kernel_version.c doing this check:
>
> if (major >= 256 || minor >= 256 || patch >= 256) {
>
> and also in kexec/kexec.h
> #define KERNEL_VERSION(major, minor, patch) \
> (((major) << 16) | ((minor) << 8) | patch)
Yeah, this seems to be a good catch. The existing longterm kenrel 4.9.262
does cause the problem. I am not very sure about the longterm kernel
version numbering, maybe we can leave 16 bits for for patch number to
avoid the longterm kernel issue?
Is there document telling the longterm kernel version numbering, or any
pointer?
Thanks
Baoquan
>
> which explains the reason for the range check in kernel_version.c
>
> Increasing the number of bits allowed in "patch" seems to fix the issue.
>
> Thanks,
> Patrick
>
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH printk v2 2/5] printk: remove safe buffers
With @logbuf_lock removed, the high level printk functions for
storing messages are lockless. Messages can be stored from any
context, so there is no need for the NMI and safe buffers anymore.
Remove the NMI and safe buffers.
Although the safe buffers are removed, the NMI and safe context
tracking is still in place. In these contexts, store the message
immediately but still use irq_work to defer the console printing.
Since printk recursion tracking is in place, safe context tracking
for most of printk is not needed. Remove it. Only safe context
tracking relating to the console lock is left in place. This is
because the console lock is needed for the actual printing.
Signed-off-by: John Ogness
---
Note: The follow-up patch removes the NMI tracking.
arch/powerpc/kernel/traps.c| 1 -
arch/powerpc/kernel/watchdog.c | 5 -
include/linux/printk.h | 10 -
kernel/kexec_core.c| 1 -
kernel/panic.c | 3 -
kernel/printk/internal.h | 17 --
kernel/printk/printk.c | 137 +-
kernel/printk/printk_safe.c| 333 +
lib/nmi_backtrace.c| 6 -
9 files changed, 56 insertions(+), 457 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 3ec7b443fe6b..7d2b339afcb0 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -170,7 +170,6 @@ extern void panic_flush_kmsg_start(void)
extern void panic_flush_kmsg_end(void)
{
- printk_safe_flush_on_panic();
kmsg_dump(KMSG_DUMP_PANIC);
bust_spinlocks(0);
debug_locks_off();
diff --git a/arch/powerpc/kernel/watchdog.c b/arch/powerpc/kernel/watchdog.c
index af3c15a1d41e..8ae46c5945d0 100644
--- a/arch/powerpc/kernel/watchdog.c
+++ b/arch/powerpc/kernel/watchdog.c
@@ -181,11 +181,6 @@ static void watchdog_smp_panic(int cpu, u64 tb)
wd_smp_unlock(&flags);
- printk_safe_flush();
- /*
-* printk_safe_flush() seems to require another print
-* before anything actually goes out to console.
-*/
if (sysctl_hardlockup_all_cpu_backtrace)
trigger_allbutself_cpu_backtrace();
diff --git a/include/linux/printk.h b/include/linux/printk.h
index fe7eb2351610..2476796c1150 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -207,8 +207,6 @@ __printf(1, 2) void dump_stack_set_arch_desc(const char
*fmt, ...);
void dump_stack_print_info(const char *log_lvl);
void show_regs_print_info(const char *log_lvl);
extern asmlinkage void dump_stack(void) __cold;
-extern void printk_safe_flush(void);
-extern void printk_safe_flush_on_panic(void);
#else
static inline __printf(1, 0)
int vprintk(const char *s, va_list args)
@@ -272,14 +270,6 @@ static inline void show_regs_print_info(const char
*log_lvl)
static inline void dump_stack(void)
{
}
-
-static inline void printk_safe_flush(void)
-{
-}
-
-static inline void printk_safe_flush_on_panic(void)
-{
-}
#endif
extern int kptr_restrict;
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index a0b6780740c8..480d5f77ef4f 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -977,7 +977,6 @@ void crash_kexec(struct pt_regs *regs)
old_cpu = atomic_cmpxchg(&panic_cpu, PANIC_CPU_INVALID, this_cpu);
if (old_cpu == PANIC_CPU_INVALID) {
/* This is the 1st CPU which comes here, so go ahead. */
- printk_safe_flush_on_panic();
__crash_kexec(regs);
/*
diff --git a/kernel/panic.c b/kernel/panic.c
index 332736a72a58..1f0df42f8d0c 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -247,7 +247,6 @@ void panic(const char *fmt, ...)
* Bypass the panic_cpu check and call __crash_kexec directly.
*/
if (!_crash_kexec_post_notifiers) {
- printk_safe_flush_on_panic();
__crash_kexec(NULL);
/*
@@ -271,8 +270,6 @@ void panic(const char *fmt, ...)
*/
atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
- /* Call flush even twice. It tries harder with a single online CPU */
- printk_safe_flush_on_panic();
kmsg_dump(KMSG_DUMP_PANIC);
/*
diff --git a/kernel/printk/internal.h b/kernel/printk/internal.h
index 51615c909b2f..6cc35c5de890 100644
--- a/kernel/printk/internal.h
+++ b/kernel/printk/internal.h
@@ -22,7 +22,6 @@ __printf(1, 0) int vprintk_deferred(const char *fmt, va_list
args);
void __printk_safe_enter(void);
void __printk_safe_exit(void);
-void printk_safe_init(void);
bool printk_percpu_data_ready(void);
#define printk_safe_enter_irqsave(flags) \
@@ -37,18 +36,6 @@ bool printk_percpu_data_ready(void);
local_irq_restore(flags); \
} while (0)
-#define printk_safe_enter_irq()\
- do {\
- local_irq_disable();\
- __printk_sa
Re: [PATCH v2 00/12] Add build ID to stacktraces
On Thu 2021-03-25 16:21:46, Stephen Boyd wrote: > Quoting peter enderborg (2021-03-25 04:06:17) > > On 3/24/21 9:55 AM, Christoph Hellwig wrote: > > > On Tue, Mar 23, 2021 at 07:04:31PM -0700, Stephen Boyd wrote: > > >> x5 : x4 : 0001 > > >> x3 : 0008 x2 : ff93fef25a70 > > >> x1 : ff93fef15788 x0 : ffe3622352e0 > > >> Call trace: > > >> lkdtm_WARNING+0x28/0x30 [lkdtm > > >> ed5019fdf5e53be37cb1ba7899292d7e143b259e] > > >> direct_entry+0x16c/0x1b4 [lkdtm > > >> ed5019fdf5e53be37cb1ba7899292d7e143b259e] > > > Yikes. No, please do not make the backtraces a complete mess for > > > something that serves absolutely no need. > > It serves a need. Please look at the patches to understand that I'm > adding the buildid to automatically find the associated debug > information on distros. > > > > > Would a "verbose" flag be acceptable solution? Something like write 1 to > > /sys/kernel/debug/verbose_stack to get the extra info. > > > > I think I see a need for it. > > > > Or a kernel config option and a commandline parameter? That would be OK > for me as I said on v1 of this series. I'll add that in for the next > patch series given all the distaste for some more hex characters next to > the module name. IMHO, a build configure option would fit the best here. It does not make sense to show the ID when the kernel vendor does not have a service to download the related binaries. But it makes sense to show the buildid by default when the provider/distro has the service and want to use the ID when handling bug reports. We could always add boot/run time options when people really need it. Best Regards, Petr ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v1 0/3] crashdump/x86: dump dax/kmem and virito-mem added System RAM
On 23.03.21 11:01, David Hildenbrand wrote: Let's properly support dumping any kind of "System RAM" that is not on the top level of the kernel resource tree in /proc/iomem, processing any /proc/iomem entry that contains "System RAM". In addition, increase the maximum number of crash memory ranges to fully support virtio-mem even in corner cases where we end up with a lot of individual memory ranges. David Hildenbrand (3): crashdump/x86: dump any kind of "System RAM" crashdump/x86: iterate only over actual crash memory ranges crashdump/x86: increase CRASH_MAX_MEMORY_RANGES to 32k kexec/arch/i386/crashdump-x86.c | 18 +- kexec/arch/i386/crashdump-x86.h | 3 ++- 2 files changed, 15 insertions(+), 6 deletions(-) Gentle ping. -- Thanks, David / dhildenb ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
