Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 大约 4 年

通知 14
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 09 5月, 2007 1 次提交
    • C
      move die notifier handling to common code · 1eeb66a1
      由 Christoph Hellwig 提交于 
      This patch moves the die notifier handling to common code.  Previous
various architectures had exactly the same code for it.  Note that the new
code is compiled unconditionally, this should be understood as an appel to
the other architecture maintainer to implement support for it aswell (aka
sprinkling a notify_die or two in the proper place)

arm had a notifiy_die that did something totally different, I renamed it to
arm_notify_die as part of the patch and made it static to the file it's
declared and used at.  avr32 used to pass slightly less information through
this interface and I brought it into line with the other architectures.

[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: fix vmalloc_sync_all bustage]
[bryan.wu@analog.com: fix vmalloc_sync_all in nommu]
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Cc: <linux-arch@vger.kernel.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NBryan Wu <bryan.wu@analog.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1eeb66a1
  3. 05 5月, 2007 1 次提交
  5. 27 3月, 2007 1 次提交
    • D
      [S390] kprobes: Align probe address. · b70842df
      由 David Wilder 提交于 
      Running a probe on s390 with a probe address that is not 4 byte aligned
results in a Kernel BUG.  The problem is that the stura instruction used
by swap_instruction requires the destination address to be 4 byte aligned.
As stura only writes 4 bytes, aligning to the next 4 byte aligned address
results in the breakpoint instruction being stored past the probe address.
The fix is to align the address backward (to the previous 4 byte aligned
address) and writing the two byte breakpoint instruction in the appropriate
bytes.

Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: NDavid Wilder <dwilder@us.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      b70842df
  7. 06 3月, 2007 1 次提交
    • M
      [S390] kprobes breaks BUG_ON · f794c827
      由 Martin Schwidefsky 提交于 
      The illegal operation handler calls the die notifier with DIE_BPT to
let kprobes pick up its breakpoint. If kprobes does not find its
breakpoint it returns NOTIFY_STOP instead of NOTIFY_DONE.
Since we use stop_machine_run on s390 to arm/disarm the kprobes
breakpoints the race that kprobe_handler tries to solve by checking
for the kprobes breakpoints does not exist. Removing the check makes
BUG_ON working again.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      f794c827
  9. 06 2月, 2007 3 次提交
  11. 08 12月, 2006 1 次提交
    • M
      [PATCH] kprobes: enable booster on the preemptible kernel · b4c6c34a
      由 Masami Hiramatsu 提交于 
      When we are unregistering a kprobe-booster, we can't release its
instruction buffer immediately on the preemptive kernel, because some
processes might be preempted on the buffer.  The freeze_processes() and
thaw_processes() functions can clean most of processes up from the buffer.
There are still some non-frozen threads who have the PF_NOFREEZE flag.  If
those threads are sleeping (not preempted) at the known place outside the
buffer, we can ensure safety of freeing.

However, the processing of this check routine takes a long time.  So, this
patch introduces the garbage collection mechanism of insn_slot.  It also
introduces the "dirty" flag to free_insn_slot because of efficiency.

The "clean" instruction slots (dirty flag is cleared) are released
immediately.  But the "dirty" slots which are used by boosted kprobes, are
marked as garbages.  collect_garbage_slots() will be invoked to release
"dirty" slots if there are more than INSNS_PER_PAGE garbage slots or if
there are no unused slots.

Cc: "Keshavamurthy, Anil S" <anil.s.keshavamurthy@intel.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: "bibo,mao" <bibo.mao@intel.com>
Cc: Prasanna S Panchamukhi <prasanna@in.ibm.com>
Cc: Yumiko Sugita <yumiko.sugita.yf@hitachi.com>
Cc: Satoshi Oshima <soshima@redhat.com>
Cc: Hideo Aoki <haoki@redhat.com>
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b4c6c34a
  13. 04 10月, 2006 1 次提交
  15. 02 10月, 2006 1 次提交
  17. 20 9月, 2006 1 次提交
  19. 17 8月, 2006 1 次提交
    • A
      [POWERPC] kprobes: Fix possible system crash during out-of-line single-stepping · 83db3dde
      由 Ananth N Mavinakayanahalli 提交于 
      - On archs that have no-exec support, we vmalloc() a executable scratch
area of PAGE_SIZE and divide it up into an array of slots of maximum
instruction size for that arch
- On a kprobe registration, the original instruction is copied to the
first available free slot, so if multiple kprobes are registered, chances
are, they get contiguous slots
- On POWER4, due to not having coherent icaches, we could hit a situation
where a probe that is registered on one processor, is hit immediately on
another. This second processor could have fetched the stream of text from
the out-of-line single-stepping area *before* the probe registration
completed, possibly due to an earlier (and a different) kprobe hit and
hence would see stale data at the slot.

Executing such an arbitrary instruction lead to a problem as reported
in LTC bugzilla 23555.

The correct solution is to call flush_icache_range() as soon as the
instruction is copied for out-of-line single-stepping, so the correct
instruction is seen on all processors.

Thanks to Will Schmidt who tracked this down.
Signed-off-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com>
Acked-by: NWill Schmidt <will_schmidt@vnet.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      83db3dde
  21. 01 7月, 2006 1 次提交
  23. 03 5月, 2006 1 次提交
  25. 20 4月, 2006 1 次提交
  27. 27 3月, 2006 2 次提交
  29. 23 3月, 2006 1 次提交
  31. 10 2月, 2006 1 次提交
  33. 12 1月, 2006 1 次提交
  35. 11 1月, 2006 4 次提交
  37. 13 12月, 2005 1 次提交
  39. 14 11月, 2005 1 次提交
  41. 07 11月, 2005 4 次提交
  43. 02 10月, 2005 1 次提交
  45. 27 9月, 2005 1 次提交
  47. 08 9月, 2005 2 次提交
  49. 06 7月, 2005 1 次提交
  51. 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
  53. 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
  55. 09 6月, 2005 1 次提交