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

Ingo Molnar
2009-01-10T15:34:46Z

* 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.

In practice i rarely see bugfixes that were debugged via kdump. Normal
oops based fixes outnumber kdump based fixes by a ratio of 1:100 or worse
- and kdump is readily available these days - just nobody configures it.

For example, in the whole kernel repo there's just 45 commits that mention
'kdump' [excluding those commits that develop kdump itself]:

$ git log --pretty=format:"%h: %s" --no-merges -i --grep="kdump" |
grep -viE 'kdump|kexec|dump|mem' | wc -l
45

Contrast that to the 1954 commits that contain the string 'oops' or
'crash':

$ git log --pretty=format:"%h: %s" --no-merges -i -E --grep="oops|crash" |
wc -l
5900

That's a ratio of 1:131. (and probably optimistic in favor of kdump.)

Note, i dont have any negative feelings towards kdump - some people use it
and enterprise folks with their frozen, immutable kernels love it - it
just has not yet given me a reason to have particularly positive feelings
towards it in the upstream kernel space.

Ingo