Re: [PATCH]: add dmesg log symbols to /proc/vmcoreinfo lists

[ebiederm@xmission.com (Eric W. Biederman)]

Simon Horman <horms@verge.net.au> writes:

>> I also did all the below.  Please check it.  (Is anyone else reading all
>> this stuff??)
>
> These look fine to me. Unfortunately they don't apply to the version
> of Linus' tree that I have checked out and I'm away from net access
> at this moment (though obviously not by the time this message reaches you).
> I'll update my tree and check once I'm back online.
>
> Eric Biederman usually watches kexec stuff. I'm pretty sure he
> is on the kexec mailing list, but I've CCed him anyway.

Thanks.

The question at head seems to be does it make sense to always
export log_buf and log_end in the VMCOREINFO section of the
core file we generate.

The premise of VMCOREINFO is that it gives crash or other
analysis tools enough information to pair a core dump with
a vmlinux and decipher the page table layout.  In general
things that are tricky to infer from just the core dump,
and the vmlinux.

Do log_buf and log_end fall in that category?

They are certainly important enough and they are symbols that
are tricky to find. That said I think we should also have 
this information exported so that we can get at
it with kgdb, jtag debuggers, and other weird debugging tools.
Do we have that already?  It doesn't look like it.  That
may be an argument for a different interface.

That aside we aren't currently exporting log_buf_len, so I don't
think this code works actually works.

Neil can you add a comment in kernel/printk.c of the algorithm
necessary for external tools to decode the ring buffer?

We need the comment because people working on kernel/printk.c
need to know what is happening and without having to review lots
of user space code, and we need the comment to verify that we
are exporting the right things.

Eric