1. 04 12月, 2009 1 次提交
  2. 13 10月, 2009 1 次提交
    • H
      x86: use kernel_stack_pointer() in kprobes.c · 98272ed0
      H. Peter Anvin 提交于
      The way to obtain a kernel-mode stack pointer from a struct pt_regs in
      32-bit mode is "subtle": the stack doesn't actually contain the stack
      pointer, but rather the location where it would have been marks the
      actual previous stack frame.  For clarity, use kernel_stack_pointer()
      instead of coding this weirdness explicitly.
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Masami Hiramatsu <mhiramat@redhat.com>
      98272ed0
  3. 30 8月, 2009 2 次提交
  4. 27 8月, 2009 3 次提交
    • F
      tracing/kprobes: Dump the culprit kprobe in case of kprobe recursion · 24851d24
      Frederic Weisbecker 提交于
      Kprobes can enter into a probing recursion, ie: a kprobe that does an
      endless loop because one of its core mechanism function used during
      probing is also probed itself.
      
      This patch helps pinpointing the kprobe that raised such recursion
      by dumping it and raising a BUG instead of a warning (we also disarm
      the kprobe to try avoiding recursion in BUG itself). Having a BUG
      instead of a warning stops the stacktrace in the right place and
      doesn't pollute the logs with hundreds of traces that eventually end
      up in a stack overflow.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Masami Hiramatsu <mhiramat@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      24851d24
    • M
      kprobes: Cleanup fix_riprel() using insn decoder on x86 · 89ae465b
      Masami Hiramatsu 提交于
      Cleanup fix_riprel() in arch/x86/kernel/kprobes.c by using the new x86
      instruction decoder instead of using comparisons with raw ad hoc numeric
      opcodes.
      Signed-off-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Frank Ch. Eigler <fche@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Jim Keniston <jkenisto@us.ibm.com>
      Cc: K.Prasad <prasad@linux.vnet.ibm.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Przemysław Pawełczyk <przemyslaw@pawelczyk.it>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      LKML-Reference: <20090813203436.31965.34374.stgit@localhost.localdomain>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      89ae465b
    • M
      kprobes: Checks probe address is instruction boudary on x86 · b46b3d70
      Masami Hiramatsu 提交于
      Ensure safeness of inserting kprobes by checking whether the specified
      address is at the first byte of an instruction on x86.
      This is done by decoding probed function from its head to the probe
      point.
      Signed-off-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Acked-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Frank Ch. Eigler <fche@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: Jim Keniston <jkenisto@us.ibm.com>
      Cc: K.Prasad <prasad@linux.vnet.ibm.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Przemysław Pawełczyk <przemyslaw@pawelczyk.it>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      LKML-Reference: <20090813203428.31965.21939.stgit@localhost.localdomain>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      b46b3d70
  5. 03 6月, 2009 1 次提交
  6. 26 3月, 2009 1 次提交
  7. 18 3月, 2009 2 次提交
  8. 17 1月, 2009 1 次提交
  9. 07 1月, 2009 1 次提交
  10. 06 1月, 2009 1 次提交
  11. 26 7月, 2008 1 次提交
    • S
      kprobes: improve kretprobe scalability with hashed locking · ef53d9c5
      Srinivasa D S 提交于
      Currently list of kretprobe instances are stored in kretprobe object (as
      used_instances,free_instances) and in kretprobe hash table.  We have one
      global kretprobe lock to serialise the access to these lists.  This causes
      only one kretprobe handler to execute at a time.  Hence affects system
      performance, particularly on SMP systems and when return probe is set on
      lot of functions (like on all systemcalls).
      
      Solution proposed here gives fine-grain locks that performs better on SMP
      system compared to present kretprobe implementation.
      
      Solution:
      
       1) Instead of having one global lock to protect kretprobe instances
          present in kretprobe object and kretprobe hash table.  We will have
          two locks, one lock for protecting kretprobe hash table and another
          lock for kretporbe object.
      
       2) We hold lock present in kretprobe object while we modify kretprobe
          instance in kretprobe object and we hold per-hash-list lock while
          modifying kretprobe instances present in that hash list.  To prevent
          deadlock, we never grab a per-hash-list lock while holding a kretprobe
          lock.
      
       3) We can remove used_instances from struct kretprobe, as we can
          track used instances of kretprobe instances using kretprobe hash
          table.
      
      Time duration for kernel compilation ("make -j 8") on a 8-way ppc64 system
      with return probes set on all systemcalls looks like this.
      
      cacheline              non-cacheline             Un-patched kernel
      aligned patch 	       aligned patch
      ===============================================================================
      real    9m46.784s       9m54.412s                  10m2.450s
      user    40m5.715s       40m7.142s                  40m4.273s
      sys     2m57.754s       2m58.583s                  3m17.430s
      ===========================================================
      
      Time duration for kernel compilation ("make -j 8) on the same system, when
      kernel is not probed.
      =========================
      real    9m26.389s
      user    40m8.775s
      sys     2m7.283s
      =========================
      Signed-off-by: NSrinivasa DS <srinivasa@in.ibm.com>
      Signed-off-by: NJim Keniston <jkenisto@us.ibm.com>
      Acked-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Masami Hiramatsu <mhiramat@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ef53d9c5
  12. 15 7月, 2008 1 次提交
    • P
      Kprobe smoke test lockdep warning · d54191b8
      Peter Zijlstra 提交于
      On Mon, 2008-04-21 at 18:54 -0400, Masami Hiramatsu wrote:
      > Thank you for reporting.
      >
      > Actually, kprobes tries to fixup thread's flags in post_kprobe_handler
      > (which is called from kprobe_exceptions_notify) by
      > trace_hardirqs_fixup_flags(pt_regs->flags). However, even the irq flag
      > is set in pt_regs->flags, true hardirq is still off until returning
      > from do_debug. Thus, lockdep assumes that hardirq is off without annotation.
      >
      > IMHO, one possible solution is that fixing hardirq flags right after
      > notify_die in do_debug instead of in post_kprobe_handler.
      
      My reply to BZ 10489:
      
      > [    2.707509] Kprobe smoke test started
      > [    2.709300] ------------[ cut here ]------------
      > [    2.709420] WARNING: at kernel/lockdep.c:2658 check_flags+0x4d/0x12c()
      > [    2.709541] Modules linked in:
      > [    2.709588] Pid: 1, comm: swapper Not tainted 2.6.25.jml.057 #1
      > [    2.709588]  [<c0126acc>] warn_on_slowpath+0x41/0x51
      > [    2.709588]  [<c010bafc>] ? save_stack_trace+0x1d/0x3b
      > [    2.709588]  [<c0140a83>] ? save_trace+0x37/0x89
      > [    2.709588]  [<c011987d>] ? kernel_map_pages+0x103/0x11c
      > [    2.709588]  [<c0109803>] ? native_sched_clock+0xca/0xea
      > [    2.709588]  [<c0142958>] ? mark_held_locks+0x41/0x5c
      > [    2.709588]  [<c0382580>] ? kprobe_exceptions_notify+0x322/0x3af
      > [    2.709588]  [<c0142aff>] ? trace_hardirqs_on+0xf1/0x119
      > [    2.709588]  [<c03825b3>] ? kprobe_exceptions_notify+0x355/0x3af
      > [    2.709588]  [<c0140823>] check_flags+0x4d/0x12c
      > [    2.709588]  [<c0143c9d>] lock_release+0x58/0x195
      > [    2.709588]  [<c038347c>] ? __atomic_notifier_call_chain+0x0/0x80
      > [    2.709588]  [<c03834d6>] __atomic_notifier_call_chain+0x5a/0x80
      > [    2.709588]  [<c0383508>] atomic_notifier_call_chain+0xc/0xe
      > [    2.709588]  [<c013b6d4>] notify_die+0x2d/0x2f
      > [    2.709588]  [<c038168a>] do_debug+0x67/0xfe
      > [    2.709588]  [<c0381287>] debug_stack_correct+0x27/0x30
      > [    2.709588]  [<c01564c0>] ? kprobe_target+0x1/0x34
      > [    2.709588]  [<c0156572>] ? init_test_probes+0x50/0x186
      > [    2.709588]  [<c04fae48>] init_kprobes+0x85/0x8c
      > [    2.709588]  [<c04e947b>] kernel_init+0x13d/0x298
      > [    2.709588]  [<c04e933e>] ? kernel_init+0x0/0x298
      > [    2.709588]  [<c04e933e>] ? kernel_init+0x0/0x298
      > [    2.709588]  [<c0105ef7>] kernel_thread_helper+0x7/0x10
      > [    2.709588]  =======================
      > [    2.709588] ---[ end trace 778e504de7e3b1e3 ]---
      > [    2.709588] possible reason: unannotated irqs-off.
      > [    2.709588] irq event stamp: 370065
      > [    2.709588] hardirqs last  enabled at (370065): [<c0382580>] kprobe_exceptions_notify+0x322/0x3af
      > [    2.709588] hardirqs last disabled at (370064): [<c0381bb7>] do_int3+0x1d/0x7d
      > [    2.709588] softirqs last  enabled at (370050): [<c012b464>] __do_softirq+0xfa/0x100
      > [    2.709588] softirqs last disabled at (370045): [<c0107438>] do_softirq+0x74/0xd9
      > [    2.714751] Kprobe smoke test passed successfully
      
      how I love this stuff...
      
      Ok, do_debug() is a trap, this can happen at any time regardless of the
      machine's IRQ state. So the first thing we do is fix up the IRQ state.
      Then we call this die notifier stuff; and return with messed up IRQ
      state... YAY.
      
      So, kprobes fudges it..
      
        notify_die(DIE_DEBUG)
          kprobe_exceptions_notify()
            post_kprobe_handler()
              modify regs->flags
              trace_hardirqs_fixup_flags(regs->flags);  <--- must be it
      
      So what's the use of modifying flags if they're not meant to take effect
      at some point.
      
      /me tries to reproduce issue; enable kprobes test thingy && boot
      
      OK, that reproduces..
      
      So the below makes it work - but I'm not getting this code; at the time
      I wrote that stuff I CC'ed each and every kprobe maintainer listed in
      the usual places but got no reposonse - can some please explain this
      stuff to me?
      
      Are the saved flags only for the TF bit or are they made in full effect
      later (and if so, where) ?
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d54191b8
  13. 17 4月, 2008 3 次提交
  14. 19 2月, 2008 1 次提交
  15. 30 1月, 2008 20 次提交