linux-kernel - Re: source line numbers with x86_64 modules? [Was: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090110153446.GA13976@elte.hu>
Date:	Sat, 10 Jan 2009 16:34:46 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Mike Snitzer <snitzer@...il.com>
Cc:	Nicholas Miell <nmiell@...cast.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	jim owens <jowens@...com>, "H. Peter Anvin" <hpa@...or.com>,
	Chris Mason <chris.mason@...cle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	paulmck@...ux.vnet.ibm.com, Gregory Haskins <ghaskins@...ell.com>,
	Matthew Wilcox <matthew@....cx>,
	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Nick Piggin <npiggin@...e.de>,
	Peter Morreale <pmorreale@...ell.com>,
	Sven Dietrich <SDietrich@...ell.com>, sam@...nborg.org,
	Dave Anderson <anderson@...hat.com>
Subject: Re: source line numbers with x86_64 modules? [Was: Re: [patch]
	measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact]


* Mike Snitzer <snitzer@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/