1. 04 2月, 2010 2 次提交
    • M
      kprobes: Check probe address is reserved · 4554dbcb
      Masami Hiramatsu 提交于
      Check whether the address of new probe is already reserved by
      ftrace or alternatives (on x86) when registering new probe.
      If reserved, it returns an error and not register the probe.
      Signed-off-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Cc: systemtap <systemtap@sources.redhat.com>
      Cc: DLE <dle-develop@lists.sourceforge.net>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: przemyslaw@pawelczyk.it
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Jim Keniston <jkenisto@us.ibm.com>
      Cc: Mathieu Desnoyers <compudj@krystal.dyndns.org>
      Cc: Jason Baron <jbaron@redhat.com>
      LKML-Reference: <20100202214918.4694.94179.stgit@dhcp-100-2-132.bos.redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4554dbcb
    • M
      kprobes: Disable booster when CONFIG_PREEMPT=y · 615d0ebb
      Masami Hiramatsu 提交于
      Disable kprobe booster when CONFIG_PREEMPT=y at this time,
      because it can't ensure that all kernel threads preempted on
      kprobe's boosted slot run out from the slot even using
      freeze_processes().
      
      The booster on preemptive kernel will be resumed if
      synchronize_tasks() or something like that is introduced.
      Signed-off-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Cc: systemtap <systemtap@sources.redhat.com>
      Cc: DLE <dle-develop@lists.sourceforge.net>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jim Keniston <jkenisto@us.ibm.com>
      Cc: Mathieu Desnoyers <compudj@krystal.dyndns.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      LKML-Reference: <20100202214904.4694.24330.stgit@dhcp-100-2-132.bos.redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      615d0ebb
  2. 28 12月, 2009 1 次提交
  3. 03 11月, 2009 1 次提交
  4. 02 10月, 2009 1 次提交
  5. 23 9月, 2009 1 次提交
  6. 17 9月, 2009 1 次提交
    • A
      kprobes: Prevent re-registration of the same kprobe · 1f0ab409
      Ananth N Mavinakayanahalli 提交于
      Prevent re-registration of the same kprobe. This situation, though
      unlikely, needs to be flagged since it can lead to a system crash if
      it's not handled.
      
      The core change itself is small, but the helper routine needed to be
      moved around a bit; hence the diffstat.
      
      Signed-off-by: Ananth N Mavinakayanahalli<ananth@in.ibm.com>
      Acked-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Cc: Jim Keniston <jkenisto@us.ibm.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Frank Ch. Eigler <fche@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: K.Prasad <prasad@linux.vnet.ibm.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <20090915051307.GB26458@in.ibm.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      1f0ab409
  7. 11 9月, 2009 1 次提交
    • M
      kprobes/x86-32: Move irq-exit functions to kprobes section · a00e817f
      Masami Hiramatsu 提交于
      Move irq-exit functions to .kprobes.text section to protect against
      kprobes recursion.
      
      When I ran kprobe stress test on x86-32, I found below symbols
      cause unrecoverable recursive probing:
      
      	ret_from_exception
      	ret_from_intr
      	check_userspace
      	restore_all
      	restore_all_notrace
      	restore_nocheck
      	irq_return
      
      And also, I found some interrupt/exception entry points that
      cause similar problems.
      
      This patch moves those symbols (including their container functions)
      to .kprobes.text section to prevent any kprobes probing.
      Signed-off-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Jim Keniston <jkenisto@us.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      LKML-Reference: <20090908164755.24050.81182.stgit@dhcp-100-2-132.bos.redhat.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      a00e817f
  8. 30 8月, 2009 1 次提交
  9. 27 8月, 2009 1 次提交
    • 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
  10. 31 7月, 2009 1 次提交
  11. 01 7月, 2009 2 次提交
  12. 09 5月, 2009 1 次提交
  13. 07 4月, 2009 4 次提交
  14. 18 3月, 2009 1 次提交
    • A
      kprobes: Fix locking imbalance in kretprobes · f02b8624
      Ananth N Mavinakayanahalli 提交于
      Fix locking imbalance in kretprobes:
      
      =====================================
      [ BUG: bad unlock balance detected! ]
      -------------------------------------
      kthreadd/2 is trying to release lock (&rp->lock) at:
      [<c06b3080>] pre_handler_kretprobe+0xea/0xf4
      but there are no more locks to release!
      
      other info that might help us debug this:
      1 lock held by kthreadd/2:
       #0:  (rcu_read_lock){..--}, at: [<c06b2b24>] __atomic_notifier_call_chain+0x0/0x5a
      
      stack backtrace:
      Pid: 2, comm: kthreadd Not tainted 2.6.29-rc8 #1
      Call Trace:
       [<c06ae498>] ? printk+0xf/0x17
       [<c06b3080>] ? pre_handler_kretprobe+0xea/0xf4
       [<c044ce6c>] print_unlock_inbalance_bug+0xc3/0xce
       [<c0444d4b>] ? clocksource_read+0x7/0xa
       [<c04450a4>] ? getnstimeofday+0x5f/0xf6
       [<c044a9ca>] ? register_lock_class+0x17/0x293
       [<c044b72c>] ? mark_lock+0x1e/0x30b
       [<c0448956>] ? tick_dev_program_event+0x4a/0xbc
       [<c0498100>] ? __slab_alloc+0xa5/0x415
       [<c06b2fbe>] ? pre_handler_kretprobe+0x28/0xf4
       [<c06b3080>] ? pre_handler_kretprobe+0xea/0xf4
       [<c044cf1b>] lock_release_non_nested+0xa4/0x1a5
       [<c06b3080>] ? pre_handler_kretprobe+0xea/0xf4
       [<c044d15d>] lock_release+0x141/0x166
       [<c06b07dd>] _spin_unlock_irqrestore+0x19/0x50
       [<c06b3080>] pre_handler_kretprobe+0xea/0xf4
       [<c06b20b5>] kprobe_exceptions_notify+0x1c9/0x43e
       [<c06b2b02>] notifier_call_chain+0x26/0x48
       [<c06b2b5b>] __atomic_notifier_call_chain+0x37/0x5a
       [<c06b2b24>] ? __atomic_notifier_call_chain+0x0/0x5a
       [<c06b2b8a>] atomic_notifier_call_chain+0xc/0xe
       [<c0442d0d>] notify_die+0x2d/0x2f
       [<c06b0f9c>] do_int3+0x1f/0x71
       [<c06b0e84>] int3+0x2c/0x34
       [<c042d476>] ? do_fork+0x1/0x288
       [<c040221b>] ? kernel_thread+0x71/0x79
       [<c043ed1b>] ? kthread+0x0/0x60
       [<c043ed1b>] ? kthread+0x0/0x60
       [<c04040b8>] ? kernel_thread_helper+0x0/0x10
       [<c043ec7f>] kthreadd+0xac/0x148
       [<c043ebd3>] ? kthreadd+0x0/0x148
       [<c04040bf>] kernel_thread_helper+0x7/0x10
      Signed-off-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com>
      Tested-by: NBharata B Rao <bharata@linux.vnet.ibm.com>
      Cc: Masami Hiramatsu <mhiramat@redhat.com>
      Cc: Jim Keniston <jkenisto@us.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: <stable@kernel.org> [2.6.29.x, 2.6.28.x, 2.6.27.x]
      LKML-Reference: <20090318113621.GB4129@in.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f02b8624
  15. 06 3月, 2009 1 次提交
  16. 17 1月, 2009 1 次提交
  17. 07 1月, 2009 6 次提交
  18. 13 11月, 2008 2 次提交
  19. 17 10月, 2008 1 次提交
  20. 26 7月, 2008 2 次提交
    • A
      kprobes: remove redundant config check · 8b6dd986
      Abhishek Sagar 提交于
      I noticed that there's a CONFIG_KPROBES check inside kernel/kprobes.c,
      which is redundant.
      Signed-off-by: NAbhishek Sagar <sagar.abhishek@gmail.com>
      Acked-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8b6dd986
    • 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
  21. 11 7月, 2008 1 次提交
  22. 13 6月, 2008 1 次提交
  23. 28 4月, 2008 4 次提交
  24. 05 3月, 2008 2 次提交