Re: 2.6.17-rc5-mm2

[Andrew Morton]

On Thu, 1 Jun 2006 09:19:27 -0700
Andrew Morton <akpm@xxxxxxxx> wrote:

> > It can't do anything
> > in that case, so the only solution I see is to either
> > - not at all call the unwinder from trap.c if the instruction pointer before the first unwind is not within kernel
> > space, or
> > - force fall-through to the old logic if the first unwind attempt didn't yield a change to either rIP or rSP (implying
> > that in that case there was no unwind information found to start with).
> > 
> > What do you think?
> 
> - Make the code robust and able to detect "unexpected" states at all
>   points through the process.  If at the end of the process we see that we
>   have encountered an unexpected state,
> 
>   - emit a diagnostic so Jan can work out if there's a way to improve
>     the unwinder in this situation
> 
>   - do a traditional backtrace as well.

Let me just agree with myself here.  It would be wildly unacceptable for
the unwinder to cause us to get _less_ information than we presently do
under any circumstances, please.  That would be a really bad impediment to
kernel development.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/