Messages in this thread |  | | | Date | Fri, 2 Jun 2006 00:13:09 -0700 | | From | Andrew Morton <> | | Subject | Re: 2.6.17-rc5-mm2 |
| |
On Fri, 02 Jun 2006 08:54:04 +0200 "Jan Beulich" <jbeulich@novell.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |