From: Omar Sandoval <osandov@osandov.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86: define arch_crash_save_vmcoreinfo() if CONFIG_CRASH_CORE=y
Date: Thu, 19 Dec 2019 12:28:07 -0800 [thread overview]
Message-ID: <20191219202807.GA826140@vader> (raw)
In-Reply-To: <20191218104113.GB24886@zn.tnic>
On Wed, Dec 18, 2019 at 11:41:13AM +0100, Borislav Petkov wrote:
> On Mon, Dec 02, 2019 at 10:02:29AM -0800, Omar Sandoval wrote:
> > From: Omar Sandoval <osandov@fb.com>
> >
> > kernel/crash_core.c calls arch_crash_save_vmcoreinfo() to get
> > arch-specific bits for vmcoreinfo. If it is not defined, then it has a
> > no-op fallback. kernel/crash_core.c is gated behind CONFIG_CRASH_CORE.
> > However, x86 defines arch_crash_save_vmcoreinfo() in
> > arch/x86/kernel/machine_kexec_*.c, which is gated behind
> > CONFIG_KEXEC_CORE. So, a kernel with CONFIG_CRASH_CORE=y and
> > CONFIG_KEXEC_CORE=n
>
> How does that even happen?
>
> Symbol: KEXEC_CORE [=y]
> Type : bool
> Defined at arch/Kconfig:17
> Selects: CRASH_CORE [=y]
> Selected by [y]:
> - KEXEC [=y]
> - KEXEC_FILE [=y] && X86_64 [=y] && CRYPTO [=y]=y && CRYPTO_SHA256 [=y]=y
>
> In order to do crash dumps, you need to select KEXEC, which selects
> KEXEC_CORE, which selects CRASH_CORE...
>
> Or are you talking about the PROC_KCORE use angle where it selects
> CRASH_CORE and the crash_save_vmcoreinfo_init() initcall is then
> supposed to save arch-specific crash info?
Yes, I'm talking about reading VMCOREINFO from /proc/kcore at runtime,
no kdump involved. crash [1] and my own tool, drgn [2], use this for
live debugging.
I can set CONFIG_PROC_KCORE=y, which selects CONFIG_CRASH_CORE=y, but if
CONFIG_KEXEC_CORE=n, the VMCOREINFO is incomplete.
1: https://github.com/crash-utility/crash/commit/60a42d709280cdf38ab06327a5b4fa9d9208ef86
2: https://github.com/osandov/drgn/blob/73dd7def1217e24cc83d8ca95c995decbd9ba24c/libdrgn/program.c#L385
next prev parent reply other threads:[~2019-12-19 20:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-02 18:02 [PATCH] x86: define arch_crash_save_vmcoreinfo() if CONFIG_CRASH_CORE=y Omar Sandoval
2019-12-18 10:41 ` Borislav Petkov
2019-12-19 20:28 ` Omar Sandoval [this message]
2019-12-20 10:05 ` Borislav Petkov
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=20191219202807.GA826140@vader \
--to=osandov@osandov.com \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.