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: <alpine.LFD.2.00.0901101454090.6528@localhost.localdomain>
Date:	Sat, 10 Jan 2009 14:58:16 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	Theodore Tso <tytso@....edu>, Mike Snitzer <snitzer@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Nicholas Miell <nmiell@...cast.net>, 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>,
	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]

On Sat, 10 Jan 2009, Andi Kleen wrote:
> 
> I think that's mostly because kexec from arbitary context is a 
> somewhat unstable concept.

I think that's the understatement of the year.

We have tons of problems with standard suspend-to-ram, and that's when the 
suspend sequence has done its best to make everything quiescent. Expecting 
that we can reinitialize all the hardware at some random point when things 
are going haywire is "optimistic" at best.

So of course it will work on some hardware and not others.

I think we've been fairly successful at keeping a running system for 
_most_ of our bugs. Even when things go bad with X running, it's quite 
often possible to ssh in over the network (although it's often better if 
you were already connected) and see the dump.

Not always, obviously. Many dumps really are painful. I'm hoping that 
kernel-mode-setting will at least give us the oops message _more_ of the 
time.

As far as I'm concerned, digital cameras have been more useful than kernel 
dumps to kernel debugging. 

			Linus
--
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/