|
http://osdir.com/ml/linux-kernel/2009-08/msg00603.html Ingo Molnar writes: > * Peter Zijlstra <a.p.zijls...@xxxxxxxxx> wrote: > > > 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. > > Yeah. > > > We could use preempt notifiers (or put in our own hooks) to > > disable callchains during the context switch I suppose. > > I think we should only disable user call-chains i think - the > in-kernel call-chain is still reliable. > > Also, i think we dont need preempt notifiers, we can use a simple > check like this: > > if (current->mm && > cpu_isset(smp_processor_id(), ¤t->mm->cpu_vm_mask) { On x86, do you clear the current processor's bit in cpu_vm_mask when you switch the MMU away from a task? We don't on powerpc, which would render the above test incorrect. (But then we don't actually have the problem on powerpc since interrupts get hard-disabled in switch_mm and stay hard-disabled until they get soft-enabled.) |
