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

[Ingo Molnar <mingo@elte.hu>]

* 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