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: <20090110222142.GI26290@one.firstfloor.org>
Date:	Sat, 10 Jan 2009 23:21:42 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Theodore Tso <tytso@....edu>, Mike Snitzer <snitzer@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	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]

> In my experience, there are very few kernel versions and hardware for
> which kdump works. 

I think that's mostly because kexec from arbitary context is a 
somewhat unstable concept. It requires all drivers to be able
to reinit the hardware from an arbitary state, and that's just
hard (it's kind of "make suspend/resume work everywhere"
and then a little harder and we know how long that took)

We also don't really have any tools to help making this
easier to implement for driver developers. Like e.g. some self
test that restarted drivers regularly to check this. 

But you often don't need kdump for crash dumps.
In many cases the system is still alive after an oops
or other problem and you can just do a live dump or even 
live crash session to look at data structures.

I used to do this with gdb regularly, but now
usually use crash because it has better tools.

> they aren't enterprise users.  Heck, until July of last year,
> Systemtap wouldn't even ***compile*** out of the box on a
> non-enterprise distribution like Ubuntu or Debian.

At least on opensuse releases it tends to work for me. 

The biggest PITA used to be the elfutils dependency which
seemed to come out of a all-world-is-redhat mindset at
the developers, but that can be worked around now.

Sometimes on has to patch it up when updating kernels 
because some interface by the runtime has changed again, but 
that shouldn't be a demanding task for kernel hackers really.
At least I didn't find it particularly difficult.

I wish they would merge the runtime into mainline though.

-Andi
-- 
ak@...ux.intel.com
--
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/