----- Original Message -----
On Mon, Feb 10, 2014 at 2:11 PM, Dave Anderson
<anderson(a)redhat.com> wrote:
>
> Hi Andy,
>
> I've got a ELF kdump vmcore that was created in-house from a kernel configured
> with CONFIG_RANDOMIZE_BASE. I thought I might be able to analyze it by applying
> your earlier patch that introduced the --kaslr option. The kernel does not
> have the offset registered in the vmcoreinfo, and so I'm trying to determine
> the offset, but with no luck.
>
> Earlier, Kees had mentioned this:
>
>>> FWIW, the offset reported during a panic to dmesg is:
>>> (unsigned long)&_text - __START_KERNEL
>
> Where does it get reported during a panic exactly? Here's the oops trace,
gotten
> by running "strings" on the vmcore:
The commit that reports it is here: f32360ef6608434a032dc7ad262d45e9693c27f3
And maybe related, but 6723734cdff15211bb78aeea76ca847374bd93ae makes
sure panic handlers are called before kmsg_dump.
And "strings" doesn't show anything starting with "Kernel
Offset:" ?
Maybe it's not being saved in the kcore?
Correct:
$ strings vmcore | grep 'Kernel Offset'
0Kernel Offset: 0x%lx from 0x%lx (relocation range: 0x%lx-0x%lx)
0Kernel Offset: 0x%lx from 0x%lx (relocation range: 0x%lx-0x%lx)
$
And that's because when kdump is enabled, crash_kexec() does not return:
void panic(const char *fmt, ...)
{
... [ cut ] ...
/*
* If we have crashed and we have a crash kernel loaded let it handle
* everything else.
* Do we want to call this before we try to display a message?
*/
crash_kexec(NULL);
/*
* Note smp_send_stop is the usual smp shutdown function, which
* unfortunately means it may not be hardened to work in a panic
* situation.
*/
smp_send_stop();
/*
* Run any panic handlers, including those that might need to
* add information to the kmsg dump output.
*/
atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
kmsg_dump(KMSG_DUMP_PANIC);
...
So for kdump, the panic_notifier_list is useless. That's why the vmcoreinfo
addition is necessary.
Dave