Re: [git pull] kgdb-light -v10

[Jason Wessel <jason.wessel@windriver.com>]

Andi Kleen wrote:
>> Basically when you reach this chunk of code it is before the hand off
>> to the source debugger.  We cannot continue because there was a
>> breakpoint in a part of the system kgdb was using while doing its
>> normal work.  The reality is that KGDB is not self contained.  It
>> relies on some external I/O methods, atomic page fault handling and
>> some other pieces.  If you take an exception there, the kgdb integrity
>> check absolutely needs to fail.
>>     
>
> Don't you just need a simple recursion counter for this? 
>
> I cannot think of a reliable simple way to check for this using the instruction
> pointer. The only way would be to use explicit annotations for all
> possible code similar to what kprobes does (__kprobes), but that would be 
> hugely intrusive all over the tree.
>
> With the recursion counter the only problem would be someone 
> setting a break point on the early notifier code itself that contains
> a recursion check, but that would be only a few lines of code
> so the risk of someone setting a break point exactly there would
> be low.
>   

It is more than a simple recursion check (which is already in the code)
because there are some conditions we can recover from.  I'd rather not
crash the system out if it can be recovered.

kgdb_reenter_check() has the "simple" recursion check with the
exception_level variable.

It also has several special checks against the breakpoint situation I
described before as well as trying to remove all the breakpoints.  
Ultimately if all those checks fails, it results in panic, because at
the end of the day that is all you can do if you re-enter the debugger
from the debugger (IE: you are toast).

I don't see any reason to change the code there unless it can be further
improved some way.  We want to fail loudly and verbosely when this kind
of thing happens so we can determine if it was the end user that caused
the problem or if there is a real defect.

Jason.