x86 NMI-safe INT3 and Page Fault
in [Kernel]
|
From: Mathieu Desnoyers on 16 Jul 2010 13:00 * Avi Kivity (avi(a)redhat.com) wrote: > On 07/16/2010 05:49 PM, Mathieu Desnoyers wrote: >> >>> You need to save/restore cr2 in addition, otherwise the following hits you >>> >>> - page fault >>> - processor writes cr2, enters fault handler >>> - nmi >>> - page fault >>> - cr2 overwritten >>> >>> I guess you would usually not notice the corruption since you'd just see >>> a spurious fault on the page the NMI handler touched, but if the first >>> fault happened in a kvm guest, then we'd corrupt the guest's cr2. >>> >> OK, just to make sure: you mean we'd have to save/restore the cr2 register >> at the beginning/end of the NMI handler execution, right ? > > Yes. OK > >> The shouldn't we >> save/restore cr3 too ? >> >> > > No, faults should not change cr3. Ah, right. > >>> But the whole thing strikes me as overkill. If it's 8k per-cpu, what's >>> wrong with using a per-cpu pointer to a kmalloc() area? >>> >> Well, it seems like all the kernel code calling "vmalloc_sync_all()" (which is >> much more than perf) can potentially cause large latencies, which could be >> squashed by allowing page faults in NMI handlers. This looks like a stronger >> argument to me. > > Why is that kernel code calling vmalloc_sync_all()? If it is only NMI > which cannot take vmalloc faults, why bother? If not, why not? Modules come as yet another example of stuff that is loaded in vmalloc'd space and can be accesses from NMI context. That would include oprofile, tracers, and probably others I'm forgetting about. Thanks, Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 16 Jul 2010 14:00 On 07/16/2010 07:58 PM, Mathieu Desnoyers wrote: > >> Why is that kernel code calling vmalloc_sync_all()? If it is only NMI >> which cannot take vmalloc faults, why bother? If not, why not? >> > Modules come as yet another example of stuff that is loaded in vmalloc'd space > and can be accesses from NMI context. That would include oprofile, tracers, and > probably others I'm forgetting about. > Module loading can certainly take a vmalloc_sync_all() (though I agree it's unpleasant). Anything else? Note perf is not modular at this time, but could be made so with preempt/sched notifiers to hook the context switch. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 16 Jul 2010 14:10 On 07/16/2010 10:54 AM, Avi Kivity wrote: > On 07/16/2010 07:58 PM, Mathieu Desnoyers wrote: >> >>> Why is that kernel code calling vmalloc_sync_all()? If it is only NMI >>> which cannot take vmalloc faults, why bother? If not, why not? >>> >> Modules come as yet another example of stuff that is loaded in vmalloc'd space >> and can be accesses from NMI context. That would include oprofile, tracers, and >> probably others I'm forgetting about. >> > > Module loading can certainly take a vmalloc_sync_all() (though I agree > it's unpleasant). Anything else? > > Note perf is not modular at this time, but could be made so with > preempt/sched notifiers to hook the context switch. > Actually, module loading is already a performance problem; a lot of distros load sometimes hundreds of modules on startup, and it's heavily serialized, so I can see this being desirable to skip. I really hope noone ever gets the idea of touching user space from an NMI handler, though, and expecting it to work... -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 16 Jul 2010 14:20 On 07/16/2010 11:15 AM, Avi Kivity wrote: > > There aren't that many processes at this time (or there shouldn't be, > don't know how fork-happy udev is at this stage), so the sync should be > pretty fast. In any case, we can sync only modules that contain NMI > handlers. > >> I really hope noone ever gets the idea of touching user space from an >> NMI handler, though, and expecting it to work... >> > > I think the concern here is about an NMI handler's code running in > vmalloc space, or is it something else? > Code or data, yes; including percpu data. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 16 Jul 2010 14:20
On 07/16/2010 09:05 PM, H. Peter Anvin wrote: > >> Module loading can certainly take a vmalloc_sync_all() (though I agree >> it's unpleasant). Anything else? >> >> Note perf is not modular at this time, but could be made so with >> preempt/sched notifiers to hook the context switch. >> >> > Actually, module loading is already a performance problem; a lot of > distros load sometimes hundreds of modules on startup, and it's heavily > serialized, so I can see this being desirable to skip. > There aren't that many processes at this time (or there shouldn't be, don't know how fork-happy udev is at this stage), so the sync should be pretty fast. In any case, we can sync only modules that contain NMI handlers. > I really hope noone ever gets the idea of touching user space from an > NMI handler, though, and expecting it to work... > I think the concern here is about an NMI handler's code running in vmalloc space, or is it something else? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |