Re: [git pull] kgdb-light -v10

[Andrew Morton <akpm@linux-foundation.org>]

On Tue, 12 Feb 2008 19:20:24 +0100 Andi Kleen <andi@firstfloor.org> wrote:

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

Yes.  A stopped CPU is very visible and hence can change the behaviour of
the system which is being tested.

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

I don't think you'd want to be poking around in kernel internals while some
of the CPUs are continuing to run.  It sounds rather creepy.  You want
everything to stop.  Including time-related things.

Bear in mind that one of the things you do with kgdb is to modify kernel
memory - I'd do things like

int foo;

	...
	if (foo == 1)
		special_stuff();
	...

to trigger a particular behaviour at a particular time.  If you're making
multiple changes, you want them "atomic" wrt all CPUs.  (Of course, if you
happeed to breakpoint one CPU while it was partway through reading multiple
locations, you lose.  But that's a teeny window).



OT: another thing you can do with kgdb is error-path testing:

	foo = kmalloc(...)
BP->	if (!foo)
		recover();

put a breakpoint on the !foo test and set foo to zero by hand.