x86 NMI-safe INT3 and Page Fault
in [Kernel]
|
From: Mathieu Desnoyers on 16 Jul 2010 14:30 * Avi Kivity (avi(a)redhat.com) wrote: > 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. USB hotplug is a use-case happening randomly after the system is well there and running; I'm afraid this does not fit in your module loading expectations. It triggers tons of events, many of these actually load modules. Thanks, Mathieu > >> 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. > -- 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:40 On 07/16/2010 09:22 PM, Mathieu Desnoyers 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. >> > USB hotplug is a use-case happening randomly after the system is well there and > running; I'm afraid this does not fit in your module loading expectations. It > triggers tons of events, many of these actually load modules. > How long would vmalloc_sync_all take with a few thousand mm_struct take? We share the pmds, yes? So it's a few thousand memory accesses. The direct impact is probably negligible, compared to actually loading the module from disk. All we need is to make sure the locking doesn't slow down unrelated stuff. -- 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: Avi Kivity on 16 Jul 2010 14:40 On 07/16/2010 09:17 PM, H. Peter Anvin wrote: > >> 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. > Use kmalloc and percpu pointers, it's not that onerous. Oh, and you can access vmalloc space by switching cr3 temporarily to init_mm's, no? Obviously not a very performant solution, at least without PCIDs, but can be used if needed. -- 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: Linus Torvalds on 16 Jul 2010 14:40 On Fri, Jul 16, 2010 at 11:15 AM, Avi Kivity <avi(a)redhat.com> wrote: > > I think the concern here is about an NMI handler's code running in vmalloc > space, or is it something else? I think the concern was also potentially doing things like backtraces etc that may need access to the module data structures (I think the ELF headers end up all being in vmalloc space too, for example). The whole debugging thing is also an issue. Now, I obviously am not a big fan of remote debuggers, but everybody tells me I'm wrong. And putting a breakpoint on NMI is certainly not insane if you are doing debugging in the first place. So it's not necessarily always about the page faults. Linus -- 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: Andi Kleen on 16 Jul 2010 15:30
> Actually, module loading is already a performance problem; a lot of > distros load sometimes hundreds of modules on startup, and it's heavily On startup you don't have many processes. If there's a problem it's surely not the fault of vmalloc_sync_all() BTW in my experience one reason module loading was traditionally slow was that it did a stop_machine(). I think(?) that has been fixed at some point. But even with that's it's more an issue on larger systems. > I really hope noone ever gets the idea of touching user space from an > NMI handler, though, and expecting it to work... It can make sense for a backtrace in a profiler. In fact perf is nearly doing it I believe, but moves it to the self IPI handler in most cases. -Andi -- ak(a)linux.intel.com -- Speaking for myself only. -- 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/ |