Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 3 年多

通知 13
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 04 2月, 2008 1 次提交
  3. 02 2月, 2008 2 次提交
  5. 01 2月, 2008 2 次提交
  7. 29 1月, 2008 1 次提交
  9. 28 1月, 2008 27 次提交
  11. 26 1月, 2008 7 次提交
    • N
      ARM kprobes: special hook for the kprobes breakpoint handler · 79696910
      由 Nicolas Pitre 提交于 
      The kprobes code is already able to cope with reentrant probes, so its
handler must be called outside of the region protected by undef_lock.

If ever this lock is released when handlers are called then this commit
could be reverted.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
      79696910
    • N
      ARM kprobes: prevent some functions involved with kprobes from being probed · 785d3cd2
      由 Nicolas Pitre 提交于 
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      785d3cd2
    • A
      ARM kprobes: core code · 24ba613c
      由 Abhishek Sagar 提交于 
      This is a full implementation of Kprobes including Jprobes and
Kretprobes support.

This ARM implementation does not follow the usual kprobes double-
exception model. The traditional model is where the initial kprobes
breakpoint calls kprobe_handler(), which returns from exception to
execute the instruction in its original context, then immediately
re-enters after a second breakpoint (or single-stepping exception)
into post_kprobe_handler(), each time the probe is hit..  The ARM
implementation only executes one kprobes exception per hit, so no
post_kprobe_handler() phase. All side-effects from the kprobe'd
instruction are resolved before returning from the initial exception.
As a result, all instructions are _always_ effectively boosted
regardless of the type of instruction, and even regardless of whether
or not there is a post-handler for the probe.
Signed-off-by: NAbhishek Sagar <sagar.abhishek@gmail.com>
Signed-off-by: NQuentin Barnes <qbarnes@gmail.com>
Signed-off-by: NNicolas Pitre <nico@marvell.com>
      24ba613c
    • Q
      ARM kprobes: instruction single-stepping support · 35aa1df4
      由 Quentin Barnes 提交于 
      This is the code implementing instruction single-stepping for kprobes
on ARM.

To get around the limitation of no Next-PC and no hardware single-
stepping, all kprobe'd instructions are split into three camps:
simulation, emulation, and rejected. "Simulated" instructions are
those instructions which behavior is reproduced by straight C code.
"Emulated" instructions are ones that are copied, slightly altered
and executed directly in the instruction slot to reproduce their
behavior.  "Rejected" instructions are ones that could be simulated,
but work hasn't been put into simulating them. These instructions
should be very rare, if not unencountered, in the kernel. If ever
needed, code could be added to simulate them.

One might wonder why this and the ptrace singlestep facility are not
sharing some code.  Both approaches are fundamentally different because
the ptrace code regains control after the stepped instruction by installing
a breakpoint after the instruction itself, and possibly at the location
where the instruction might be branching to, instead of simulating or
emulating the target instruction.

The ptrace approach isn't suitable for kprobes because the breakpoints
would have to be moved back, and the icache flushed, everytime the
probe is hit to let normal code execution resume, which would have a
significant performance impact. It is also racy on SMP since another
CPU could, with the right timing, sail through the probe point without
being caught.  Because ptrace single-stepping always result in a
different process to be scheduled, the concern for performance is much
less significant.

On the other hand, the kprobes approach isn't (currently) suitable for
ptrace because it has no provision for proper user space memory
protection and translation, and even if that was implemented, the gain
wouldn't be worth the added complexity in the ptrace path compared to
the current approach.

So, until kprobes does support user space, both kprobes and ptrace are
best kept independent and separate.
Signed-off-by: NQuentin Barnes <qbarnes@gmail.com>
Signed-off-by: NAbhishek Sagar <sagar.abhishek@gmail.com>
Signed-off-by: NNicolas Pitre <nico@marvell.com>
      35aa1df4
    • R
      [ARM] pxa: Add PXA3 standby code hooked into the IRQ wake scheme · 7b5dea12
      由 Russell King 提交于 
      Wakeup sources on PXA3 are enabled at two levels.  First, the MFP
configuration has to be set to enable which edges a specific pin
will trigger a wakeup.  The pin also has to be routed to a functional
unit.  Lastly, the functional unit must be enabled as a wakeup source
in the appropriate AD*ER registers (AD2D0ER for standby resume.)

This doesn't fit well with the IRQ wake scheme - we currently do a
best effort conversion from IRQ numbers to functional unit wake enable
bits.  For instance, there's several USB client related enable bits but
there's no corresponding IRQs to determine which you'd want.  Conversely,
there's a single enable bit covering several functional units.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7b5dea12
    • E
      [ARM] pxa: make MFP configuration processor independent · 7f7c8a61
      由 eric miao 提交于 
      There are two reasons for making the MFP configuration to be processor
independent, i.e. removing the relationship of configuration bits with
actual MFPR register settings:

   1. power management sometimes requires the MFP to be configured
      differently when in run mode or in low power mode

   2. for future integration of pxa{25x,27x} GPIO configurations

The modifications include:

1. introducing of processor independent MFP configuration bits, as
   defined in [include/asm-arm/arch-pxa/mfp.h]:

	bit  0.. 9 - MFP Pin Number (1024 Pins Maximum)
	bit 10..12 - Alternate Function Selection
	bit 13..15 - Drive Strength
	bit 16..18 - Low Power Mode State
	bit 19..20 - Low Power Mode Edge Detection
	bit 21..22 - Run Mode Pull State
	and so on,

2. moving the processor dependent code from mfp.h into mfp-pxa3xx.h

3. cleaning up of the MFPR bit definitions

4. mapping of processor independent MFP configuration into processor
   specific MFPR register settings is now totally encapsulated within
   pxa3xx_mfp_config()

5. using of "unsigned long" instead of invented type of "mfp_cfg_t"
   according to Documentation/CodingStyle Chapter 5, usage of this
   in platform code will be slowly removed in later patches
Signed-off-by: Neric miao <eric.miao@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7f7c8a61
    • E
      [ARM] pxa: remove un-used pxa3xx_mfp_set_xxx() functions · 0ad1fbc8
      由 eric miao 提交于 
      pxa3xx_mfp_set_xxx() functions are originally provided for overwriting
MFP configurations performed by pxa3xx_mfp_config(), the usage of such
a dirtry trick is not recommended, since there is currently no user of
these functions, they are safely removed
Signed-off-by: Neric miao <eric.miao@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      0ad1fbc8