| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The offset to the pt_regs area was wrong, so we weren't
looking at the right location for the magic cookie.
A trap frame is composed of a "struct sparc_stackf" then
a "struct pt_regs", the code was using "struct reg_window"
instead of "struct sparc_stackf".
Signed-off-by: David S. Miller <[email protected]>
|
|
Now that we have a magic cookie in the pt_regs, we can
properly detect trap frames in stack bactraces.
Signed-off-by: David S. Miller <[email protected]>
|
|
Doing a 'flushw' every stack trace capture creates so much overhead
that it makes lockdep next to unusable.
We only care about the frame pointer chain and the function caller
program counters, so flush those by hand to the stack frame.
This is significantly more efficient than a 'flushw' because:
1) We only save 16 bytes per active register window to the stack.
2) This doesn't push the entire register window context of the current
call chain out of the cpu, forcing register window fill traps as we
return back down.
Note that we can't use 'restore' and 'save' instructions to move
around the register windows because that wouldn't work on Niagara
processors. They optimize 'save' into a new register window by
simply clearing out the registers instead of pulling them in from
the on-chip register window backing store.
Based upon a report by Tom Callaway.
Signed-off-by: David S. Miller <[email protected]>
|
|
Simplify the stacktrace code:
- remove the unused task argument to save_stack_trace, it's always
current
- remove the all_contexts flag, it's alwasy 0
Signed-off-by: Christoph Hellwig <[email protected]>
Cc: Paul Mundt <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: Martin Schwidefsky <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Akinobu Mita <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Signed-off-by: David S. Miller <[email protected]>
|