Re: source line numbers with x86_64 modules? [Was: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact]

Ingo Molnar
2009-01-11T01:29:22Z

* Mike Snitzer <snitzer@gmail.com> wrote:

> On Sat, Jan 10, 2009 at 10:34 AM, Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Mike Snitzer <snitzer@gmail.com> wrote:
> >
> >> Yes, especially from someone who lacks the ability to properly
> >> configure kdump. I'm fairly surprised others are giving you a free
> >> pass when you keep asserting how broken kdump is with such hollow
> >> criticism. I rely heavily on kdump and it works quite well (kvm
> >> integration was lacking but has improved).
> >
> > hm, you say you rely heavily on kdump ... for what exactly, and how
> > does it help the upstream Linux kernel?
> >
> > I see a single fix from you in the whole repository:
> >
> > ffc41cf: nbd: prevent sock_xmit from attempting to use a NULL socket
> >
> > ... and that single fix is a NULL pointer dereference that ought to have
> > been quite debuggable from a plain oops alone.
>
> I've reported various bugs and helped with prototypes for fixes (e.g.
> a0da84f3). But by all means belittle me... must be fun.

I really did not want to belittle you - but in hindsight it really reads
that way ... sorry about that and how insensitive it was from me! :(

I just wanted to point out that if kdump is useful it must be _visible_.
Ask commit logs to include "this was debugged via kdump" lines, etc. The
upstream kernel must feel that it all matters.

The upstream kernel really has to be ruthless about such things and must
react to how things are not to how things are wished to be - one of the
most critical things is that keeps Linux ticking is people like you who
report and debug problems.

Note, back when kdump was added to the kernel many moons ago i strongly
supported it and helped out with the patches, etc. I still think it might
have the potential to become big - but it needs a ton of tech and care to
reach that level of convenience.

'kdump light' perhaps that dumps the most important data structures like
registers of all CPUs, task struct and the symbol tables, the current task
itself including the kernel stack plus the surrounding 4K of all pointers
that are in current registers and that point into kernel memory - maybe
straight to kerneloops.org [if the user agrees] - or something like that.

Ingo