1. 28 Jun, 2005 36 commits
  2. 27 Jun, 2005 4 commits
    • Keshavamurthy Anil S's avatar
      [PATCH] kprobes/ia64: refuse kprobe on ivt code · c7b645f9
      Keshavamurthy Anil S authored
      Not safe to insert kprobes on IVT code.
      
      This patch checks to see if the address on which Kprobes is being inserted is
      in ivt code and if it is in ivt code then refuse to register kprobe.
      Signed-off-by: default avatarAnil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Acked-by: default avatarDavid Mosberger <davidm@napali.hpl.hp.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c7b645f9
    • Rusty Lynch's avatar
      [PATCH] kprobes/ia64: refuse inserting kprobe on slot 1 · a528e21c
      Rusty Lynch authored
      Without the ability to atomically write 16 bytes, we can not update the
      middle slot of a bundle, slot 1, unless we stop the machine first.  This
      patch will ensure the ability to robustly insert and remove a kprobe by
      refusing to insert a kprobe on slot 1 until a mechanism is in place to
      safely handle this case.
      Signed-off-by: default avatarRusty Lynch <rusty.lynch@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a528e21c
    • Rusty Lynch's avatar
      [PATCH] Return probe redesign: ppc64 specific implementation · 97f7943d
      Rusty Lynch authored
      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: default avatarRusty Lynch <rusty.lynch@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      97f7943d
    • Rusty Lynch's avatar
      [PATCH] Return probe redesign: ia64 specific implementation · 9508dbfe
      Rusty Lynch authored
      The following patch implements function return probes for ia64 using
      the revised design.  With this new design we no longer need to do some
      of the odd hacks previous required on the last ia64 return probe port
      that I sent out for comments.
      
      Note that this new implementation still does not resolve the problem noted
      by Keith Owens where backtrace data is lost after a return probe is hit.
      
      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: default avatarRusty Lynch <rusty.lynch@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      9508dbfe