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]

Date:	Tue, 12 Feb 2008 19:20:24 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>, 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

>  - the kgdb commands should always act on the *current* CPU only
>  - add one command that says "switch over to CPU #n" which just releases 
>    the current CPU and sends an IPI to that CPU #n (no timeouts, no 
>    synchronous waiting, no nothing - it's like a "continue", but with a 
>    "try to get the other CPU to stop"

The problem I see here is that the kernel tends to get badly confused
if one CPU just stops responding. At some point someone does an global
IPI and that then hangs.  You would need to hotunplug the CPU which
is theoretically possible, but quite intrusive. Or maybe the "isolate CPUs 
in cpusets" frame work someone posted recently on l-k could be used.  Still 
would probably have all kinds of tricky issues and races.

-Andi

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