1. 14 10月, 2008 4 次提交
    • S
      ftrace: x86 use copy to and from user functions · 6f93fc07
      Steven Rostedt 提交于
      The modification of code is performed either by kstop_machine, before
      SMP starts, or on module code before the module is executed. There is
      no reason to do the modifications from assembly. The copy to and from
      user functions are sufficient and produces cleaner and easier to read
      code.
      
      Thanks to Benjamin Herrenschmidt for suggesting the idea.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      6f93fc07
    • S
      ftrace: use only 5 byte nops for x86 · 732f3ca7
      Steven Rostedt 提交于
      Mathieu Desnoyers revealed a bug in the original code. The nop that is
      used to relpace the mcount caller can be a two part nop. This runs the
      risk where a process can be preempted after executing the first nop, but
      before the second part of the nop.
      
      The ftrace code calls kstop_machine to keep multiple CPUs from executing
      code that is being modified, but it does not protect against a task preempting
      in the middle of a two part nop.
      
      If the above preemption happens and the tracer is enabled, after the
      kstop_machine runs, all those nops will be calls to the trace function.
      If the preempted process that was preempted between the two nops is executed
      again, it will execute half of the call to the trace function, and this
      might crash the system.
      
      This patch instead uses what both the latest Intel and AMD spec suggests.
      That is the P6_NOP5 sequence of "0x0f 0x1f 0x44 0x00 0x00".
      
      Note, some older CPUs and QEMU might fault on this nop, so this nop
      is executed with fault handling first. If it detects a fault, it will then
      use the code "0x66 0x66 0x66 0x66 0x90". If that faults, it will then
      default to a simple "jmp 1f; .byte 0x00 0x00 0x00; 1:". The jmp is
      not optimal but will do if the first two can not be executed.
      
      TODO: Examine the cpuid to determine the nop to use.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      732f3ca7
    • S
      ftrace: x86 mcount stub · 0a37605c
      Steven Rostedt 提交于
      x86 now sets up the mcount locations through the build and no longer
      needs to record the ip when the function is executed. This patch changes
      the initial mcount to simply return. There's no need to do any other work.
      If the ftrace start up test fails, the original mcount will be what everything
      will use, so having this as fast as possible is a good thing.
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0a37605c
    • I
      ftrace: mark lapic_wd_event() notrace · 8b1fa1d7
      Ingo Molnar 提交于
      it can be called in the NMI path:
      
      [    0.645999] calling  ftrace_dynamic_init+0x0/0xd6
      [    0.647521] ------------[ cut here ]------------
      [    0.647521] WARNING: at kernel/trace/ftrace.c:348 ftrace_record_ip+0x4e/0x252()
      [    0.647521] Modules linked in:
      [    0.647521] Pid: 15, comm: kstop1 Not tainted 2.6.27-rc1-tip #22686
      [    0.647521]
      [    0.647521] Call Trace:
      [    0.647521]  <NMI>  [<ffffffff8024593f>] warn_on_slowpath+0x5d/0x84
      [    0.647521]  [<ffffffff80220b99>] ? lapic_wd_event+0xb/0x5c
      [    0.647521]  [<ffffffff80287b3b>] ftrace_record_ip+0x4e/0x252
      [    0.647521]  [<ffffffff80211274>] mcount_call+0x5/0x31
      [    0.647521]  [<ffffffff80220b9e>] ? lapic_wd_event+0x10/0x5c
      [    0.647521]  [<ffffffff8083f3ec>] nmi_watchdog_tick+0x19d/0x1ad
      [    0.647521]  [<ffffffff8083e875>] default_do_nmi+0x75/0x1e3
      [    0.647521]  [<ffffffff8083f0b3>] do_nmi+0x5d/0x94
      [    0.647521]  [<ffffffff8083e2d2>] nmi+0xa2/0xc2
      [    0.647521]  [<ffffffff802b48c3>] ? check_bytes_and_report+0x11/0xcc
      [    0.647521]  <<EOE>>  [<ffffffff80211274>] ? mcount_call+0x5/0x31
      [    0.647521]  [<ffffffff802b49df>] check_object+0x61/0x1b0
      [    0.647521]  [<ffffffff802b502a>] __slab_free+0x169/0x2ae
      [    0.647521]  [<ffffffff80242dbf>] ? __cleanup_sighand+0x25/0x27
      [    0.647521]  [<ffffffff80242dbf>] ? __cleanup_sighand+0x25/0x27
      [    0.647521]  [<ffffffff802b60cd>] kmem_cache_free+0x85/0xb9
      [    0.647521]  [<ffffffff80242dbf>] __cleanup_sighand+0x25/0x27
      [    0.647521]  [<ffffffff80247b3d>] release_task+0x256/0x339
      [    0.647521]  [<ffffffff802490b4>] do_exit+0x764/0x7ef
      [    0.647521]  [<ffffffff8027624c>] __xchg+0x0/0x38
      [    0.647521]  [<ffffffff8027619a>] ? stop_cpu+0x0/0xb2
      [    0.647521]  [<ffffffff8027619a>] ? stop_cpu+0x0/0xb2
      [    0.647521]  [<ffffffff8025922f>] kthread+0x4e/0x7b
      [    0.647521]  [<ffffffff80212979>] child_rip+0xa/0x11
      [    0.647521]  [<ffffffff80211c17>] ? restore_args+0x0/0x30
      [    0.647521]  [<ffffffff802283a5>] ? native_load_tls+0x14/0x2e
      [    0.647521]  [<ffffffff802591e1>] ? kthread+0x0/0x7b
      [    0.647521]  [<ffffffff8021296f>] ? child_rip+0x0/0x11
      [    0.647521]
      [    0.647521] ---[ end trace 4eaa2a86a8e2da22 ]---
      [    0.672032] initcall ftrace_dynamic_init+0x0/0xd6 returned 0 after 19 msecs
      
      also mark it no-kprobes while at it.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8b1fa1d7
  2. 13 10月, 2008 36 次提交