[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <221183717.69773903.1547497592624.JavaMail.zimbra@redhat.com>
Date: Mon, 14 Jan 2019 15:26:32 -0500 (EST)
From: Dave Anderson <anderson@...hat.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Kazuhito Hagio <k-hagio@...jp.nec.com>,
Lianbo Jiang <lijiang@...hat.com>,
linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
tglx@...utronix.de, mingo@...hat.com, x86@...nel.org,
akpm@...ux-foundation.org, bhe@...hat.com, dyoung@...hat.com,
linux-doc@...r.kernel.org
Subject: Re: [PATCH 1/2 v6] kdump: add the vmcoreinfo documentation
----- Original Message -----
> On Mon, Jan 14, 2019 at 03:07:33PM -0500, Dave Anderson wrote:
> > That's what it *does* utilize -- it takes a standalone vmcore dumpfile, and
> > pulls out the OSRELEASE string from it, so that a user can determine what
> > vmlinux file should be used with that vmcore for normal crash analysis.
>
> And the vmcoreinfo is part of the vmcore, right?
Correct.
>
> So it can just as well read out the address of init_uts_ns and get the
> kernel version from there.
No. It needs *both* the vmlinux file and the vmcore file in order to read kernel
virtual memory, so just having a kernel virtual address is insufficient.
So it's a chicken-and-egg situation. This particular --osrelease option is used
to determine *what* vmlinux file would be required for an actual crash analysis
session.
Dave
Powered by blists - more mailing lists