Re: 2.6.17-rc5-mm2

[Andrew Morton]

On Fri, 02 Jun 2006 08:54:04 +0200
"Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> >- 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,
> 
> The problem is that the unwind is expected to end with an odd state (i.e. fail), at least until all possible root
> points of execution (i.e. bottoms of call stacks) have a proper annotation forcing their parent program counter to zero
> (which I don't expect to happen soon, if ever, because I think this is something difficult to prove). Thus the only
> reasonable thing to do is to check whether the first level of unwinding failed.
> 

Are there other heuristics we can apply?  For example, we have a pretty
good idea whereabouts the top of a kernel stack is.  If we don't end up
close to that offset then we can assume that something went wrong?

> >  - 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.
> 
> This might be a config or boot option (and might be forced on for a short while), but I generally don't think this is
> helpful, given that the entire point of the added logic is to remove (useless) information (even more that if you have
> to rely on the screen alone, you have to live with its limited size, and pushing out an old-style stack trace after the
> unwound one would likely make part or all of it as well as the register information disappear).
> 

Plus a config or boot option is too late.


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