linux-kernel - Re: [git pull] kgdb-light -v10

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: <20080212170110.GA31428@elte.hu>
Date:	Tue, 12 Feb 2008 18:01:10 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Roland McGrath <roland@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [git pull] kgdb-light -v10

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> In other words, is it perhaps possible to just *get*rid*of* that 
> "kgdb_active" and "nmicallback" and the whole multi-CPU roundup? Just 
> use a kgdb spinlock around the stuff that actually sends and receives 
> individual packets, and expect the debugger side to sort them out 
> (yeah, I suspect this involves having to add the CPU ID to each 
> packet).

i actually think that the notion of "stopping all system state" is 
rather intuitive from a debugging POV: when you have a bug trigger 
somewhere then getting an NMI to all CPUs and stopping them dead in 
their tracks preserves us the system in its most useful state.

also, when using kgdb to "look at system state" it's best to have as 
little "unrelated" activity as possible.

the timeout argument brought up by Andi was IMO really just pulled here 
by its hair, it never happened to me in practice and i was surprised it 
even came up. (i never before saw "KGDB roundup" fail - and i tried it 
on an 8-way system too) I think the memory-access routine cleanups were 
far more interesting from a failure scenario POV. Maybe Andrew could 
shed some light on his experience and preference here - he's been using 
KGDB for many years.

	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/