From: "David A. Long" <dave.long(a)linaro.org>
This patch series adds basic uprobes support to ARM. It is based on patches
developed earlier by Rabin Vincent. That approach of adding special cases into
the kprobes instruction parsing code was not well received. This approach
separates the ARM instruction parsing code in kprobes out into a separate set
of functions which can be used by both kprobes and uprobes. Both kprobes and
uprobes then provide their own semantic action tables to process the results of
the parsing.
One regression bug fix is still in progress on this, and some more definitions
may be moved from kprobes*.h files into more generic include files. However,
at this point feedback on the basic approach would be appreciated.
These patches are based on v3.10-rc7
David A. Long (3):
uprobes: move function declarations out of arch
ARM: Separate kprobes instruction parsing into routines
ARM: add uprobes support
Rabin Vincent (4):
uprobes: allow ignoring of probe hits
uprobes: allow arch access to xol slot
uprobes: allow arch-specific initialization
uprobes: add arch write opcode hook
arch/arm/Kconfig | 4 +
arch/arm/include/asm/kprobes.h | 17 +-
arch/arm/include/asm/probes.h | 23 ++
arch/arm/include/asm/ptrace.h | 6 +
arch/arm/include/asm/thread_info.h | 5 +-
arch/arm/include/asm/uprobes.h | 34 ++
arch/arm/kernel/Makefile | 3 +-
arch/arm/kernel/kprobes-arm.c | 495 ++++++-----------------------
arch/arm/kernel/kprobes-common.c | 260 +---------------
arch/arm/kernel/kprobes-thumb.c | 31 +-
arch/arm/kernel/kprobes.c | 7 +-
arch/arm/kernel/kprobes.h | 51 +--
arch/arm/kernel/probes-arm.h | 66 ++++
arch/arm/kernel/probes.c | 624 +++++++++++++++++++++++++++++++++++++
arch/arm/kernel/signal.c | 4 +
arch/arm/kernel/uprobes-arm.c | 220 +++++++++++++
arch/arm/kernel/uprobes.c | 203 ++++++++++++
arch/arm/kernel/uprobes.h | 25 ++
arch/powerpc/include/asm/uprobes.h | 1 -
arch/x86/include/asm/uprobes.h | 7 -
include/linux/uprobes.h | 17 +
kernel/events/uprobes.c | 54 +++-
22 files changed, 1426 insertions(+), 731 deletions(-)
create mode 100644 arch/arm/include/asm/probes.h
create mode 100644 arch/arm/include/asm/uprobes.h
create mode 100644 arch/arm/kernel/probes-arm.h
create mode 100644 arch/arm/kernel/probes.c
create mode 100644 arch/arm/kernel/uprobes-arm.c
create mode 100644 arch/arm/kernel/uprobes.c
create mode 100644 arch/arm/kernel/uprobes.h
--
1.8.1.2
More than 256 entries in ACPI MADT is supported from ACPI 3.0 Specification,
So the outdated description for MADT entries should be removed.
Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org>
---
Documentation/cpu-hotplug.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
index 9f40135..2e36e40 100644
--- a/Documentation/cpu-hotplug.txt
+++ b/Documentation/cpu-hotplug.txt
@@ -370,9 +370,6 @@ A: There is no clear spec defined way from ACPI that can give us that
CPUs in MADT as hotpluggable CPUS. In the case there are no disabled CPUS
we assume 1/2 the number of CPUs currently present can be hotplugged.
- Caveat: Today's ACPI MADT can only provide 256 entries since the apicid field
- in MADT is only 8 bits.
-
User Space Notification
Hotplug support for devices is common in Linux today. Its being used today to
--
1.7.9.5
This is a first draft at a process for getting things integrated into
the Linaro Stable Kernel releases. Any feedback is appreciated,
hopefully this is all fairly boring and uncontroversial so there
shouldn't be too many surprises.
The first thing to say here is that all LSK releases will be based off
the latest generic Linux stable kernel so the best way to get a change
into a Linaro release is to get it into the generic Linux stable kernel
using the standard processes. This will maximise the number of people
who can use the change and is just generally good practice.
New features
------------
Features for the stable kernel are agreed by the TSC. Once a feature
has been agreed by the TSC there should be an owner assigned to deliver
a feature branch into the stable kernel and work with the stable kernel
team to resolve any integration issues at least up until the feature has
been included in a release. This will be done per kernel version.
These feature branches should be based on the relevant upstream kernel
as far as possible (any dependencies on other branches should be
discussed with the stable kernel team). Some information about where
the code came fromm should be included along with the code, in order of
preference:
1. Commit IDs from the standard kernel in the changelogs of the
individual patches.
2. A description of how the equivalent change was made upstream or
why it isn't required in LSK (eg, explaining that this is taken
care of by features not present in the stable kernel).
3. References to where out of tree development is happening
including contact information for followup.
The code should be sent as a pull request or patches, with review by the
stable team following normal kernel process and focusing on backporting
and integration issues. Relevant testing infrastructure should also be
available in LAVA for QA and the review will also include ensuring that
the testsuite passes with the changes integrated.
Once the code has been accepted it will be stored as a branch in the LSK
tree and the submission branch can be deleted.
Updating code in the LSK
------------------------
The LSK can be updated either by replacing an existing topic branch or
by submitting incremental patches. Replacement would be most useful in
cases where a feature has not yet been merged into the standard kernel
and is still being redeveloped there but otherwise incremental updates
are preferred. The process for submitting changes is the same as for
new features with the exception that incremental updates should be based
on the topic branch in the LSK git rather than the standard kernel.