1. 01 7月, 2006 1 次提交
  2. 03 5月, 2006 1 次提交
  3. 20 4月, 2006 1 次提交
  4. 27 3月, 2006 2 次提交
  5. 23 3月, 2006 1 次提交
  6. 10 2月, 2006 1 次提交
  7. 12 1月, 2006 1 次提交
  8. 11 1月, 2006 4 次提交
  9. 13 12月, 2005 1 次提交
  10. 14 11月, 2005 1 次提交
  11. 07 11月, 2005 4 次提交
  12. 02 10月, 2005 1 次提交
  13. 27 9月, 2005 1 次提交
  14. 08 9月, 2005 2 次提交
  15. 06 7月, 2005 1 次提交
  16. 28 6月, 2005 2 次提交
    • R
      [PATCH] Return probe redesign: ppc64 specific implementation · 97f7943d
      Rusty Lynch 提交于
      The following is a patch provided by Ananth Mavinakayanahalli that implements
      the new PPC64 specific parts of the new function return probe design.
      
      NOTE: Since getting Ananth's patch, I changed trampoline_probe_handler()
            to consume each of the outstanding return probem instances (feedback
            on my original RFC after Ananth cut a patch), and also added the
            arch_init() function (adding arch specific initialization.) I have
            cross compiled but have not testing this on a PPC64 machine.
      
      Changes include:
       * Addition of kretprobe_trampoline to act as a dummy function for instrumented
         functions to return to, and for the return probe infrastructure to place
         a kprobe on on, gaining control so that the return probe handler
         can be called, and so that the instruction pointer can be moved back
         to the original return address.
       * Addition of arch_init(), allowing a kprobe to be registered on
         kretprobe_trampoline
       * Addition of trampoline_probe_handler() which is used as the pre_handler
         for the kprobe inserted on kretprobe_implementation.  This is the function
         that handles the details for calling the return probe handler function
         and returning control back at the original return address
       * Addition of arch_prepare_kretprobe() which is setup as the pre_handler
         for a kprobe registered at the beginning of the target function by
         kernel/kprobes.c so that a return probe instance can be setup when
         a caller enters the target function.  (A return probe instance contains
         all the needed information for trampoline_probe_handler to do it's job.)
       * Hooks added to the exit path of a task so that we can cleanup any left-over
         return probe instances (i.e. if a task dies while inside a targeted function
         then the return probe instance was reserved at the beginning of the function
         but the function never returns so we need to mark the instance as unused.)
      Signed-off-by: NRusty Lynch <rusty.lynch@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      97f7943d
    • A
      [PATCH] kprobes: fix single-step out of line - take2 · 9ec4b1f3
      Ananth N Mavinakayanahalli 提交于
      Now that PPC64 has no-execute support, here is a second try to fix the
      single step out of line during kprobe execution.  Kprobes on x86_64 already
      solved this problem by allocating an executable page and using it as the
      scratch area for stepping out of line.  Reuse that.
      Signed-off-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9ec4b1f3
  17. 24 6月, 2005 2 次提交
    • P
      [PATCH] kprobes: Temporary disarming of reentrant probe for ppc64 · 42cc2060
      Prasanna S Panchamukhi 提交于
      This patch includes ppc64 architecture specific changes to support temporary
      disarming on reentrancy of probes.
      Signed-of-by: NPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      42cc2060
    • R
      [PATCH] Move kprobe [dis]arming into arch specific code · 7e1048b1
      Rusty Lynch 提交于
      The architecture independent code of the current kprobes implementation is
      arming and disarming kprobes at registration time.  The problem is that the
      code is assuming that arming and disarming is a just done by a simple write
      of some magic value to an address.  This is problematic for ia64 where our
      instructions look more like structures, and we can not insert break points
      by just doing something like:
      
      *p->addr = BREAKPOINT_INSTRUCTION;
      
      The following patch to 2.6.12-rc4-mm2 adds two new architecture dependent
      functions:
      
           * void arch_arm_kprobe(struct kprobe *p)
           * void arch_disarm_kprobe(struct kprobe *p)
      
      and then adds the new functions for each of the architectures that already
      implement kprobes (spar64/ppc64/i386/x86_64).
      
      I thought arch_[dis]arm_kprobe was the most descriptive of what was really
      happening, but each of the architectures already had a disarm_kprobe()
      function that was really a "disarm and do some other clean-up items as
      needed when you stumble across a recursive kprobe." So...  I took the
      liberty of changing the code that was calling disarm_kprobe() to call
      arch_disarm_kprobe(), and then do the cleanup in the block of code dealing
      with the recursive kprobe case.
      
      So far this patch as been tested on i386, x86_64, and ppc64, but still
      needs to be tested in sparc64.
      Signed-off-by: NRusty Lynch <rusty.lynch@intel.com>
      Signed-off-by: NAnil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7e1048b1
  18. 09 6月, 2005 3 次提交
  19. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4