x86 NMI-safe INT3 and Page Fault
in [Kernel]
|
From: Andi Kleen on 16 Jul 2010 15:40 On Fri, Jul 16, 2010 at 11:25:19AM -0700, Linus Torvalds wrote: > 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. We already have infrastructure for kprobes to prevent breakpoints on critical code (the __kprobes section). In principle kgdb/kdb could be taught about honoring those too. That wouldn't help for truly external JTAG debuggers, but I would assume those generally can (should) handle any contexts anyways. -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/
From: Andi Kleen on 16 Jul 2010 15:40 On Fri, Jul 16, 2010 at 09:32:00PM +0300, Avi Kivity wrote: > 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. Also you have to remember that vmalloc_sync_all() only does something when the top level page is actually updated. That is very rare. (in many cases it should happen at most once per boot) Most mapping changes update lower levels, and those are already shared. -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/
From: Avi Kivity on 16 Jul 2010 15:40 On 07/16/2010 10:28 PM, Andi Kleen wrote: > >> 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. > Interesting, is the self IPI guaranteed to execute synchronously after the NMI's IRET? Or can the core IRET faster than the APIC and so we get the backtrace at the wrong place? (and does it matter? the NMI itself is not always accurate) -- 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 15:40 On 07/16/2010 11:32 AM, Avi Kivity wrote: > > 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. > It's not the memory accesses, it's the need to synchronize all the CPUs. -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 15:50
On 07/16/2010 10:29 PM, H. Peter Anvin wrote: > On 07/16/2010 11:32 AM, Avi Kivity wrote: > >> 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. >> >> > It's not the memory accesses, it's the need to synchronize all the CPUs. > I'm missing something. Why do we need to sync all cpus? the vmalloc_sync_all() I'm reading doesn't. Even if we do an on_each_cpu() somewhere, it isn't the end of the world. -- 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/ |