Ben H. suggested there might be a problem if we get a PMU interrupt
and try to do a stack trace of userspace in the interval between when
we call switch_mm() from sched.c:context_switch() and when we call
switch_to(). If we get an NMI in that interval and do a stack trace
of userspace, we'll see the registers of the old task but when we peek
at user addresses we'll see the memory image for the new task, so the
stack trace we get will be completely bogus.
Is this in fact also a problem on x86, or is there some subtle reason
why it can't happen there?
Paul.
On Tue, 2009-07-28 at 14:49 +1000, Paul Mackerras wrote:
> Ben H. suggested there might be a problem if we get a PMU interrupt
> and try to do a stack trace of userspace in the interval between when
> we call switch_mm() from sched.c:context_switch() and when we call
> switch_to(). If we get an NMI in that interval and do a stack trace
> of userspace, we'll see the registers of the old task but when we peek
> at user addresses we'll see the memory image for the new task, so the
> stack trace we get will be completely bogus.
>
> Is this in fact also a problem on x86, or is there some subtle reason
> why it can't happen there?
I can't spot one, maybe Ingo can when he's back :-)
So I think this is very good spotting from Ben.
We could use preempt notifiers (or put in our own hooks) to disable
callchains during the context switch I suppose.
Peter Zijlstra <[email protected]> writes:
> We could use preempt notifiers (or put in our own hooks) to disable
> callchains during the context switch I suppose.
You can simply check if cr3 matches the current->mm page tables
and not dump if they are not.
-Andi
--
[email protected] -- Speaking for myself only.