lkml.org 
[lkml]   [2006]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: BUG-lockdep and freeze (was: Arrr! Linux 2.6.18)


On Sun, 1 Oct 2006, Andi Kleen wrote:
>
> On i386 it is simpler (only one interrupt stack and one process stack)
> However there can be still nasty corner cases, like the temporary NMI stacks
> that were added recently. It could be probably all handled in a state machine,
> but it would be ugly (at least I heard complaints about the x86 code that
> does it)

No, I don't understand AT ALL why you are so hung up about this state
machine thing. It's not true. There's simply no state machine involved,
although from a theoretical standpoint you can obviously always implement
just about _anything_ as a state machine.

> > Read the x86 code. Please. The one _before_ you added unwinding.
>
> It's still the same if you disable unwinding.

I think your problem is that you think that "unwinding" needs to handle
all the page crossing. That's incorrect, and that just results in stupid
and unworkable code.

Instead (and this is why I was trying to point you to the original
pre-unwinding code on i386), what you should do is to see it as two
totally independent phases:

- you have an outer loop that loops around the pages (since the _kernel_
controls the stack nesting at that level). This is the loop I quoted at
you.

- you have a _separate_ "unwinder()" for each page. It only unwinds
within that one page, and if the frame moves away from the page, it
immediately just returns that address, but it knows that it cannot be a
"valid" unwind address within that page.

That separate "unwind within one page" can well be using the dwarf info:
it only really needs to verify that
- it stays within the same page
- the unwind info results in an aligned pointer at a strictly higher
address.
those two tests are trivial, and _guarantee_ that we don't access any
half-way untrustworthy pointer.

See? No state machine. And notice how the dwarf info absolutely does _not_
need to know about the magic page-crossing events like interrupts,
exceptions or anything else. Very much on purpose.

This is what we used to do with %ebp following (at least on x86), and what
I tried to explain. Nothing complicated. And it's easy to set up, and the
dawrf unwinder (which depends on complex data structures) can be trivially
verified (ie it just stops immediately when it doesn't understand
something, and "crosses a page" is such an event).

And the page-crossing events don't need to know _anything_ about the dwarf
format (or %ebp, or any other unwinding details), and it can just depend
on the chain of pages (which is trivial to set up - if the exception pages
aren't already using the same format as the interrupt stack pages, it
should at least not be hard to make them do that).

And the page-level unwinding data format is trivial. I don't think we even
bothered verifying it on x86, but I guess some simple sanity-checking even
there might be worth it (but unlike any dwarf unwinding, this is _not_ at
all complicated, and there are absolutely _zero_ issues about compiler and
linker versions etc etc).

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

\
 
 \ /
  Last update: 2009-11-18 23:46    [from the cache]
©2003-2011 Jasper Spaans