1. 23 6月, 2013 1 次提交
    • S
      trace,x86: Do not call local_irq_save() in load_current_idt() · 2b4bc789
      Steven Rostedt (Red Hat) 提交于
      As load_current_idt() is now what is used to update the IDT for the
      switches needed for NMI, lockdep debug, and for tracing, it must not
      call local_irq_save(). This is because one of the users of this is
      lockdep, which does tracing of local_irq_save() and when the debug
      trap is hit, we need to update the IDT before tracing interrupts
      being disabled. As load_current_idt() is used to do this, calling
      local_irq_save() which lockdep traces, defeats the point of calling
      load_current_idt().
      
      As interrupts are already disabled when used by lockdep and NMI, the
      only other user is tracing that can disable interrupts itself. Simply
      have the tracing update disable interrupts before calling load_current_idt()
      instead of breaking the other users.
      
      Here's the dump that happened:
      
      ------------[ cut here ]------------
      WARNING: at /work/autotest/nobackup/linux-test.git/kernel/fork.c:1196 copy_process+0x2c3/0x1398()
      DEBUG_LOCKS_WARN_ON(!p->hardirqs_enabled)
      Modules linked in:
      CPU: 1 PID: 4570 Comm: gdm-simple-gree Not tainted 3.10.0-rc3-test+ #5
      Hardware name:                  /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006
       ffffffff81d2a7a5 ffff88006ed13d50 ffffffff8192822b ffff88006ed13d90
       ffffffff81035f25 ffff8800721c6000 ffff88006ed13da0 0000000001200011
       0000000000000000 ffff88006ed5e000 ffff8800721c6000 ffff88006ed13df0
      Call Trace:
       [<ffffffff8192822b>] dump_stack+0x19/0x1b
       [<ffffffff81035f25>] warn_slowpath_common+0x67/0x80
       [<ffffffff81035fe1>] warn_slowpath_fmt+0x46/0x48
       [<ffffffff812bfc5d>] ? __raw_spin_lock_init+0x31/0x52
       [<ffffffff810341f7>] copy_process+0x2c3/0x1398
       [<ffffffff8103539d>] do_fork+0xa8/0x260
       [<ffffffff810ca7b1>] ? trace_preempt_on+0x2a/0x2f
       [<ffffffff812afb3e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
       [<ffffffff81937fe7>] ? sysret_check+0x1b/0x56
       [<ffffffff81937fe7>] ? sysret_check+0x1b/0x56
       [<ffffffff810355cf>] SyS_clone+0x16/0x18
       [<ffffffff81938369>] stub_clone+0x69/0x90
       [<ffffffff81937fc2>] ? system_call_fastpath+0x16/0x1b
      ---[ end trace 8b157a9d20ca1aa2 ]---
      
      in fork.c:
      
       #ifdef CONFIG_PROVE_LOCKING
      	DEBUG_LOCKS_WARN_ON(!p->hardirqs_enabled); <-- bug here
      	DEBUG_LOCKS_WARN_ON(!p->softirqs_enabled);
       #endif
      
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      2b4bc789
  2. 21 6月, 2013 2 次提交
    • S
      x86, trace: Add irq vector tracepoints · cf910e83
      Seiji Aguchi 提交于
      [Purpose of this patch]
      
      As Vaibhav explained in the thread below, tracepoints for irq vectors
      are useful.
      
      http://www.spinics.net/lists/mm-commits/msg85707.html
      
      <snip>
      The current interrupt traces from irq_handler_entry and irq_handler_exit
      provide when an interrupt is handled.  They provide good data about when
      the system has switched to kernel space and how it affects the currently
      running processes.
      
      There are some IRQ vectors which trigger the system into kernel space,
      which are not handled in generic IRQ handlers.  Tracing such events gives
      us the information about IRQ interaction with other system events.
      
      The trace also tells where the system is spending its time.  We want to
      know which cores are handling interrupts and how they are affecting other
      processes in the system.  Also, the trace provides information about when
      the cores are idle and which interrupts are changing that state.
      <snip>
      
      On the other hand, my usecase is tracing just local timer event and
      getting a value of instruction pointer.
      
      I suggested to add an argument local timer event to get instruction pointer before.
      But there is another way to get it with external module like systemtap.
      So, I don't need to add any argument to irq vector tracepoints now.
      
      [Patch Description]
      
      Vaibhav's patch shared a trace point ,irq_vector_entry/irq_vector_exit, in all events.
      But there is an above use case to trace specific irq_vector rather than tracing all events.
      In this case, we are concerned about overhead due to unwanted events.
      
      So, add following tracepoints instead of introducing irq_vector_entry/exit.
      so that we can enable them independently.
         - local_timer_vector
         - reschedule_vector
         - call_function_vector
         - call_function_single_vector
         - irq_work_entry_vector
         - error_apic_vector
         - thermal_apic_vector
         - threshold_apic_vector
         - spurious_apic_vector
         - x86_platform_ipi_vector
      
      Also, introduce a logic switching IDT at enabling/disabling time so that a time penalty
      makes a zero when tracepoints are disabled. Detailed explanations are as follows.
       - Create trace irq handlers with entering_irq()/exiting_irq().
       - Create a new IDT, trace_idt_table, at boot time by adding a logic to
         _set_gate(). It is just a copy of original idt table.
       - Register the new handlers for tracpoints to the new IDT by introducing
         macros to alloc_intr_gate() called at registering time of irq_vector handlers.
       - Add checking, whether irq vector tracing is on/off, into load_current_idt().
         This has to be done below debug checking for these reasons.
         - Switching to debug IDT may be kicked while tracing is enabled.
         - On the other hands, switching to trace IDT is kicked only when debugging
           is disabled.
      
      In addition, the new IDT is created only when CONFIG_TRACING is enabled to avoid being
      used for other purposes.
      Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
      Link: http://lkml.kernel.org/r/51C323ED.5050708@hds.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      cf910e83
    • S
      x86: Rename variables for debugging · 629f4f9d
      Seiji Aguchi 提交于
      Rename variables for debugging to describe meaning of them precisely.
      
      Also, introduce a generic way to switch IDT by checking a current state,
      debug on/off.
      Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
      Link: http://lkml.kernel.org/r/51C323A8.7050905@hds.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      629f4f9d
  3. 15 5月, 2012 1 次提交
  4. 22 12月, 2011 1 次提交
    • S
      x86: Keep current stack in NMI breakpoints · 228bdaa9
      Steven Rostedt 提交于
      We want to allow NMI handlers to have breakpoints to be able to
      remove stop_machine from ftrace, kprobes and jump_labels. But if
      an NMI interrupts a current breakpoint, and then it triggers a
      breakpoint itself, it will switch to the breakpoint stack and
      corrupt the data on it for the breakpoint processing that it
      interrupted.
      
      Instead, have the NMI check if it interrupted breakpoint processing
      by checking if the stack that is currently used is a breakpoint
      stack. If it is, then load a special IDT that changes the IST
      for the debug exception to keep the same stack in kernel context.
      When the NMI is done, it puts it back.
      
      This way, if the NMI does trigger a breakpoint, it will keep
      using the same stack and not stomp on the breakpoint data for
      the breakpoint it interrupted.
      Suggested-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      228bdaa9
  5. 05 8月, 2011 1 次提交
  6. 27 5月, 2011 1 次提交
  7. 06 11月, 2009 1 次提交
    • C
      x86: Make sure get_user_desc() doesn't sign extend. · 2c75910f
      Chris Lalancette 提交于
      The current implementation of get_user_desc() sign extends the return
      value because of integer promotion rules.  For the most part, this
      doesn't matter, because the top bit of base2 is usually 0.  If, however,
      that bit is 1, then the entire value will be 0xffff...  which is
      probably not what the caller intended.
      
      This patch casts the entire thing to unsigned before returning, which
      generates almost the same assembly as the current code but replaces the
      final "cltq" (sign extend) with a "mov %eax %eax" (zero-extend).  This
      fixes booting certain guests under KVM.
      Signed-off-by: NChris Lalancette <clalance@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2c75910f
  8. 20 7月, 2009 1 次提交
  9. 18 6月, 2009 1 次提交
  10. 22 4月, 2009 1 次提交
    • D
      FRV: Fix the section attribute on UP DECLARE_PER_CPU() · 9b8de747
      David Howells 提交于
      In non-SMP mode, the variable section attribute specified by DECLARE_PER_CPU()
      does not agree with that specified by DEFINE_PER_CPU().  This means that
      architectures that have a small data section references relative to a base
      register may throw up linkage errors due to too great a displacement between
      where the base register points and the per-CPU variable.
      
      On FRV, the .h declaration says that the variable is in the .sdata section, but
      the .c definition says it's actually in the .data section.  The linker throws
      up the following errors:
      
      kernel/built-in.o: In function `release_task':
      kernel/exit.c:78: relocation truncated to fit: R_FRV_GPREL12 against symbol `per_cpu__process_counts' defined in .data section in kernel/built-in.o
      kernel/exit.c:78: relocation truncated to fit: R_FRV_GPREL12 against symbol `per_cpu__process_counts' defined in .data section in kernel/built-in.o
      
      To fix this, DECLARE_PER_CPU() should simply apply the same section attribute
      as does DEFINE_PER_CPU().  However, this is made slightly more complex by
      virtue of the fact that there are several variants on DEFINE, so these need to
      be matched by variants on DECLARE.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9b8de747
  11. 11 3月, 2009 1 次提交
  12. 24 12月, 2008 1 次提交
    • Y
      x86: fix lguest used_vectors breakage, -v2 · b77b881f
      Yinghai Lu 提交于
      Impact: fix lguest, clean up
      
      32-bit lguest used used_vectors to record vectors, but that model of
      allocating vectors changed and got broken, after we changed vector
      allocation to a per_cpu array.
      
      Try enable that for 64bit, and the array is used for all vectors that
      are not managed by vector_irq per_cpu array.
      
      Also kill system_vectors[], that is now a duplication of the
      used_vectors bitmap.
      
      [ merged in cpus4096 due to io_apic.c cpumask changes. ]
      [ -v2, fix build failure ]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b77b881f
  13. 23 10月, 2008 2 次提交
  14. 13 10月, 2008 1 次提交
  15. 28 7月, 2008 1 次提交
  16. 24 7月, 2008 1 次提交
  17. 23 7月, 2008 1 次提交
  18. 12 7月, 2008 1 次提交
  19. 08 7月, 2008 1 次提交
  20. 13 5月, 2008 1 次提交
  21. 17 4月, 2008 1 次提交
  22. 30 1月, 2008 9 次提交
  23. 11 10月, 2007 1 次提交