On 19 November 2014 20:25, David Long wrote:
>> I was thinking of the magic hex numbers in the kprobes decode tables,
>> which
>> seem to correspond directly to the instruction classes described in insn.c
>>
>> Keeping the actual emulation code separate makes sense.
>>
>> Will
>
>
> Of course
On 18 November 2014 20:26, Will Deacon wrote:
> One thing I noticed looking through this patch is that we're effectively
> reinventing a bunch of the instruction decoding logic that we already have
> in the kernel (introduced since Sandeepa last sent his patch).
>
> Could you take a look at
On 18 November 2014 20:26, Will Deacon will.dea...@arm.com wrote:
One thing I noticed looking through this patch is that we're effectively
reinventing a bunch of the instruction decoding logic that we already have
in the kernel (introduced since Sandeepa last sent his patch).
Could you take
On 19 November 2014 20:25, David Long dave.l...@linaro.org wrote:
I was thinking of the magic hex numbers in the kprobes decode tables,
which
seem to correspond directly to the instruction classes described in insn.c
Keeping the actual emulation code separate makes sense.
Will
Of course
On 24 April 2014 02:02, Tanmay Inamdar wrote:
> Hello Sandeepa,
>
> On Tue, Apr 22, 2014 at 4:50 AM, Sandeepa Prabhu
> wrote:
>> On 22 April 2014 15:41, Liviu Dudau wrote:
>>> On Tue, Apr 22, 2014 at 09:58:28AM +0100, Sandeepa Prabhu wrote:
>>>> On
On 24 April 2014 02:02, Tanmay Inamdar tinam...@apm.com wrote:
Hello Sandeepa,
On Tue, Apr 22, 2014 at 4:50 AM, Sandeepa Prabhu
sandeepa.pra...@linaro.org wrote:
On 22 April 2014 15:41, Liviu Dudau liviu.du...@arm.com wrote:
On Tue, Apr 22, 2014 at 09:58:28AM +0100, Sandeepa Prabhu wrote
On 22 April 2014 15:41, Liviu Dudau wrote:
> On Tue, Apr 22, 2014 at 09:58:28AM +0100, Sandeepa Prabhu wrote:
>> On 14 March 2014 21:04, Liviu Dudau wrote:
>> > Hi,
>> >
>> > This patch adds support for PCI to AArch64. It is based on my v7 patch
>> >
On 14 March 2014 21:04, Liviu Dudau wrote:
> Hi,
>
> This patch adds support for PCI to AArch64. It is based on my v7 patch
> that adds support for creating generic host bridge structure from
> device tree. With that in place, I was able to boot a platform that
> has PCIe host bridge support and
On 14 March 2014 21:04, Liviu Dudau liviu.du...@arm.com wrote:
Hi,
This patch adds support for PCI to AArch64. It is based on my v7 patch
that adds support for creating generic host bridge structure from
device tree. With that in place, I was able to boot a platform that
has PCIe host bridge
On 22 April 2014 15:41, Liviu Dudau liviu.du...@arm.com wrote:
On Tue, Apr 22, 2014 at 09:58:28AM +0100, Sandeepa Prabhu wrote:
On 14 March 2014 21:04, Liviu Dudau liviu.du...@arm.com wrote:
Hi,
This patch adds support for PCI to AArch64. It is based on my v7 patch
that adds support
>> I am not sure if this question is related, uprobes or ftrace code does
>> not define __kprobes, so is it safe to place kprobe on uprobes or
>> ftrace code?
>
> Yes, it is "safe" in qualitative meaning. But for ftrace code, it could
> give a performance impact by miss-hitting. Since uprobe is
> OK, I think the kprobe is like a strong medicine, not a toy,
> since it can intercept most of the kernel functions which
> may process a sensitive user private data. Thus even if we
> fix all bugs and make it safe, I don't think we can open
> it for all users (of course, there should be a knob
OK, I think the kprobe is like a strong medicine, not a toy,
since it can intercept most of the kernel functions which
may process a sensitive user private data. Thus even if we
fix all bugs and make it safe, I don't think we can open
it for all users (of course, there should be a knob to
I am not sure if this question is related, uprobes or ftrace code does
not define __kprobes, so is it safe to place kprobe on uprobes or
ftrace code?
Yes, it is safe in qualitative meaning. But for ftrace code, it could
give a performance impact by miss-hitting. Since uprobe is independent
On 4 December 2013 13:09, Masami Hiramatsu
wrote:
> (2013/12/04 11:54), Sandeepa Prabhu wrote:
>> On 4 December 2013 06:58, Masami Hiramatsu
>> wrote:
>>> Hi,
>>> Here is the version 4 of NOKPORBE_SYMBOL series.
>>>
>>> In this version, I re
On 4 December 2013 13:09, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2013/12/04 11:54), Sandeepa Prabhu wrote:
On 4 December 2013 06:58, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
Hi,
Here is the version 4 of NOKPORBE_SYMBOL series.
In this version, I removed
ry.S: do_dbg to route
software breakpoint (BRK64) exception to do_debug_exception()
Signed-off-by: Sandeepa Prabhu
Signed-off-by: Deepak Saxena
Acked-by: Will Deacon
---
arch/arm64/include/asm/debug-monitors.h | 21
arch/arm64/kernel/debug-monitors.c
mmit ID: dc1ccc48159d63eca5089e507c82c7d22ef60839 (Linux 3.13-rc2)
- CCing Jason Wessel, since arm64 kgdb patchset is dependant on this.
Sandeepa Prabhu (1):
arm64: support single-step and breakpoint handler hooks
arch/arm64/include/asm/debug-monitors.h | 21
arch/arm64/kerne
On 4 December 2013 06:58, Masami Hiramatsu
wrote:
> Hi,
> Here is the version 4 of NOKPORBE_SYMBOL series.
>
> In this version, I removed the cleanup patches and
> add bugfixes I've found, since those bugs will be
> critical.
> Rest of the cleanup and visible blacklists will be
> proposed later
Thu, Oct 17, 2013 at 12:17:46PM +0100, Sandeepa Prabhu wrote:
>> AArch64 Single Steping and Breakpoint debug exceptions will be
>> used by multiple debug framworks like kprobes & kgdb.
>>
>> This patch implements the hooks for those frameworks to register
>> their
, Oct 17, 2013 at 12:17:46PM +0100, Sandeepa Prabhu wrote:
AArch64 Single Steping and Breakpoint debug exceptions will be
used by multiple debug framworks like kprobes kgdb.
This patch implements the hooks for those frameworks to register
their own handlers for handling breakpoint and single
On 4 December 2013 06:58, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
Hi,
Here is the version 4 of NOKPORBE_SYMBOL series.
In this version, I removed the cleanup patches and
add bugfixes I've found, since those bugs will be
critical.
Rest of the cleanup and visible blacklists
: dc1ccc48159d63eca5089e507c82c7d22ef60839 (Linux 3.13-rc2)
- CCing Jason Wessel, since arm64 kgdb patchset is dependant on this.
Sandeepa Prabhu (1):
arm64: support single-step and breakpoint handler hooks
arch/arm64/include/asm/debug-monitors.h | 21
arch/arm64/kernel/debug-monitors.c
: do_dbg to route
software breakpoint (BRK64) exception to do_debug_exception()
Signed-off-by: Sandeepa Prabhu sandeepa.pra...@linaro.org
Signed-off-by: Deepak Saxena dsax...@linaro.org
Acked-by: Will Deacon will.dea...@arm.com
---
arch/arm64/include/asm/debug-monitors.h | 21
arch/arm64
On 18 November 2013 12:25, Sandeepa Prabhu wrote:
>>> This is generic test module (samples/hw_breakpoint/data_breakpoint.ko)
>>> which places watchpoint for bothe read/write.
>>> Atleast watchpt should have triggered for Read right? I also tried
>>> with othe
On 18 November 2013 12:25, Sandeepa Prabhu sandeepa.pra...@linaro.org wrote:
This is generic test module (samples/hw_breakpoint/data_breakpoint.ko)
which places watchpoint for bothe read/write.
Atleast watchpt should have triggered for Read right? I also tried
with othe functions like do_fork
>> This is generic test module (samples/hw_breakpoint/data_breakpoint.ko)
>> which places watchpoint for bothe read/write.
>> Atleast watchpt should have triggered for Read right? I also tried
>> with othe functions like do_fork, vfs_read etc but no hit.
>
> You'd need to place something for exec
On 15 November 2013 22:07, Will Deacon wrote:
>> well, kprobes does not step from kernel address, but it prepares a
>> allocated memory(executable), copies the instruction and update the
>> single step address (ELR) to enable stepping while ERET.
>> So, don't we need NOP at next location after
On 15 November 2013 22:12, Will Deacon wrote:
> On Thu, Nov 14, 2013 at 11:04:04AM +0000, Sandeepa Prabhu wrote:
>> Hi Jean,
>>
>> I have applied this patchset on aarch64 upstream branch,cross-compiled
>> for arm64 and try running some tests for hardware breakpoints.
On 15 November 2013 22:12, Will Deacon will.dea...@arm.com wrote:
On Thu, Nov 14, 2013 at 11:04:04AM +, Sandeepa Prabhu wrote:
Hi Jean,
I have applied this patchset on aarch64 upstream branch,cross-compiled
for arm64 and try running some tests for hardware breakpoints.
I cross-compiled
On 15 November 2013 22:07, Will Deacon will.dea...@arm.com wrote:
well, kprobes does not step from kernel address, but it prepares a
allocated memory(executable), copies the instruction and update the
single step address (ELR) to enable stepping while ERET.
So, don't we need NOP at next
This is generic test module (samples/hw_breakpoint/data_breakpoint.ko)
which places watchpoint for bothe read/write.
Atleast watchpt should have triggered for Read right? I also tried
with othe functions like do_fork, vfs_read etc but no hit.
You'd need to place something for exec if you
On 14 November 2013 16:45, Jean Pihet wrote:
> Hi Sandeepa,
>
> On Thu, Nov 14, 2013 at 12:04 PM, Sandeepa Prabhu
> wrote:
>> Hi Jean,
>>
>> I have applied this patchset on aarch64 upstream branch,cross-compiled
>> for arm64 and try running some tests for
Hi Jean,
I have applied this patchset on aarch64 upstream branch,cross-compiled
for arm64 and try running some tests for hardware breakpoints.
I cross-compiled perf using linaro toolchain
"gcc-linaro-aarch64-linux-gnu-4.7-2013.04-20130415_linux" as
$ cd tools/perf/
$ make LDFLAGS=-static
Hi Jean,
I have applied this patchset on aarch64 upstream branch,cross-compiled
for arm64 and try running some tests for hardware breakpoints.
I cross-compiled perf using linaro toolchain
gcc-linaro-aarch64-linux-gnu-4.7-2013.04-20130415_linux as
$ cd tools/perf/
$ make LDFLAGS=-static
On 14 November 2013 16:45, Jean Pihet jean.pi...@newoldbits.com wrote:
Hi Sandeepa,
On Thu, Nov 14, 2013 at 12:04 PM, Sandeepa Prabhu
sandeepa.pra...@linaro.org wrote:
Hi Jean,
I have applied this patchset on aarch64 upstream branch,cross-compiled
for arm64 and try running some tests
On 13 November 2013 20:01, Will Deacon wrote:
> On Wed, Nov 13, 2013 at 06:55:33AM +0000, Sandeepa Prabhu wrote:
>> >>> I'm unsure about arm64's debug feature behavior, what does happen when
>> >>> it performs a single-step on sw-breakpoint?
>> >>
On 13 November 2013 20:01, Will Deacon will.dea...@arm.com wrote:
On Wed, Nov 13, 2013 at 06:55:33AM +, Sandeepa Prabhu wrote:
I'm unsure about arm64's debug feature behavior, what does happen when
it performs a single-step on sw-breakpoint?
Sandeepa: I think you need to retry
On 13 November 2013 12:25, Sandeepa Prabhu wrote:
>>>> I'm unsure about arm64's debug feature behavior, what does happen when
>>>> it performs a single-step on sw-breakpoint?
>>>>
>>>>> Sandeepa: I think you need to retry Masami's test on
On 12 November 2013 15:47, Masami Hiramatsu
wrote:
> (2013/11/12 17:44), Sandeepa Prabhu wrote:
>> On 12 November 2013 12:57, Masami Hiramatsu
>> wrote:
>>> (2013/11/12 15:23), Sandeepa Prabhu wrote:
>>>>>>> OK, I've ensured that the hw_breakpoint (f
On 12 November 2013 12:57, Masami Hiramatsu
wrote:
> (2013/11/12 15:23), Sandeepa Prabhu wrote:
>>>>> OK, I've ensured that the hw_breakpoint (from perf) can work
>>>>> with kprobes (from ftrace) at the same address on x86.
>>>>> So if arm64 alrea
On 12 November 2013 12:57, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2013/11/12 15:23), Sandeepa Prabhu wrote:
OK, I've ensured that the hw_breakpoint (from perf) can work
with kprobes (from ftrace) at the same address on x86.
So if arm64 already support hw_breakpoint on perf
On 12 November 2013 15:47, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2013/11/12 17:44), Sandeepa Prabhu wrote:
On 12 November 2013 12:57, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2013/11/12 15:23), Sandeepa Prabhu wrote:
OK, I've ensured that the hw_breakpoint
On 13 November 2013 12:25, Sandeepa Prabhu sandeepa.pra...@linaro.org wrote:
I'm unsure about arm64's debug feature behavior, what does happen when
it performs a single-step on sw-breakpoint?
Sandeepa: I think you need to retry Masami's test on the arm64 model,
since
I'm fairly sure
On 11 November 2013 16:51, Will Deacon wrote:
> On Mon, Nov 11, 2013 at 05:35:37AM +0000, Sandeepa Prabhu wrote:
>> On 8 November 2013 22:26, Will Deacon wrote:
>> >> diff --git a/arch/arm64/include/asm/kprobes.h
>> >> b/arch/arm64/include/asm/kprobes.h
>&
>>> OK, I've ensured that the hw_breakpoint (from perf) can work
>>> with kprobes (from ftrace) at the same address on x86.
>>> So if arm64 already support hw_breakpoint on perf, kprobes should
>>> work with it.
>>
>> Single-stepping on x86 is different to the step behaviour on arm64 afaik. On
>>
On 11 November 2013 13:23, AKASHI Takahiro wrote:
> On 11/11/2013 01:29 PM, Sandeepa Prabhu wrote:
>>
>> On 8 November 2013 22:34, Will Deacon wrote:
>>>>
>>>> +static inline long regs_return_value(struct pt_regs *regs)
>>>> +{
>>>&g
On 11 November 2013 13:23, AKASHI Takahiro takahiro.aka...@linaro.org wrote:
On 11/11/2013 01:29 PM, Sandeepa Prabhu wrote:
On 8 November 2013 22:34, Will Deacon will.dea...@arm.com wrote:
+static inline long regs_return_value(struct pt_regs *regs)
+{
+ return regs-regs[0
OK, I've ensured that the hw_breakpoint (from perf) can work
with kprobes (from ftrace) at the same address on x86.
So if arm64 already support hw_breakpoint on perf, kprobes should
work with it.
Single-stepping on x86 is different to the step behaviour on arm64 afaik. On
ARM, we have to
On 11 November 2013 16:51, Will Deacon will.dea...@arm.com wrote:
On Mon, Nov 11, 2013 at 05:35:37AM +, Sandeepa Prabhu wrote:
On 8 November 2013 22:26, Will Deacon will.dea...@arm.com wrote:
diff --git a/arch/arm64/include/asm/kprobes.h
b/arch/arm64/include/asm/kprobes.h
new file
On 8 November 2013 22:33, Will Deacon wrote:
> On Thu, Oct 17, 2013 at 12:17:48PM +0100, Sandeepa Prabhu wrote:
>> Add support for AArch64 instruction simulation in kprobes.
>>
>> Kprobes need simulation of instructions that cannot be stepped
>> right-away from dif
On 9 November 2013 14:40, Masami Hiramatsu
wrote:
> (2013/11/09 1:56), Will Deacon wrote:
>> Hi Sandeepa,
>>
>> On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
>>> Add support for basic kernel probes(kprobes), jump probes (jprobes)
>>&g
On 8 November 2013 22:26, Will Deacon wrote:
> Hi Sandeepa,
>
> On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
>> Add support for basic kernel probes(kprobes), jump probes (jprobes)
>> for ARM64.
>
> I think this series will conflict quite heavily
On 8 November 2013 22:34, Will Deacon wrote:
> On Thu, Oct 17, 2013 at 12:17:49PM +0100, Sandeepa Prabhu wrote:
>> AArch64 ISA does not instructions to pop PC register value
>> from stack(like ARM v7 has ldmia {...,pc}) without using
>> one of the general purpose registe
On 8 November 2013 22:34, Will Deacon will.dea...@arm.com wrote:
On Thu, Oct 17, 2013 at 12:17:49PM +0100, Sandeepa Prabhu wrote:
AArch64 ISA does not instructions to pop PC register value
from stack(like ARM v7 has ldmia {...,pc}) without using
one of the general purpose registers. This means
On 8 November 2013 22:26, Will Deacon will.dea...@arm.com wrote:
Hi Sandeepa,
On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
Add support for basic kernel probes(kprobes), jump probes (jprobes)
for ARM64.
I think this series will conflict quite heavily with the jump_label
On 9 November 2013 14:40, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2013/11/09 1:56), Will Deacon wrote:
Hi Sandeepa,
On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
Add support for basic kernel probes(kprobes), jump probes (jprobes)
for ARM64.
I think
On 8 November 2013 22:33, Will Deacon will.dea...@arm.com wrote:
On Thu, Oct 17, 2013 at 12:17:48PM +0100, Sandeepa Prabhu wrote:
Add support for AArch64 instruction simulation in kprobes.
Kprobes need simulation of instructions that cannot be stepped
right-away from different memory location
On 25 October 2013 20:54, Will Deacon wrote:
> On Thu, Oct 17, 2013 at 12:17:51PM +0100, Sandeepa Prabhu wrote:
>> Add info prints in sample kprobe handlers for ARM and ARM64
>> architecture.
>>
>> Signed-off-by: Sandeepa Prabhu
>> ---
>>
On 25 October 2013 20:54, Will Deacon will.dea...@arm.com wrote:
On Thu, Oct 17, 2013 at 12:17:51PM +0100, Sandeepa Prabhu wrote:
Add info prints in sample kprobe handlers for ARM and ARM64
architecture.
Signed-off-by: Sandeepa Prabhu sandeepa.pra...@linaro.org
---
samples/kprobes
On 3 November 2013 23:55, Jiang Liu wrote:
> On 10/30/2013 08:12 AM, Will Deacon wrote:
>> Hi Jinag Liu,
>>
>> Sorry for the delayed review, I've been travelling.
>>
>> On Fri, Oct 18, 2013 at 04:19:56PM +0100, Jiang Liu wrote:
>>> From: Jiang Liu
>>
>> If I try and email you at your Huawei
On 3 November 2013 23:55, Jiang Liu liu...@gmail.com wrote:
On 10/30/2013 08:12 AM, Will Deacon wrote:
Hi Jinag Liu,
Sorry for the delayed review, I've been travelling.
On Fri, Oct 18, 2013 at 04:19:56PM +0100, Jiang Liu wrote:
From: Jiang Liu jiang@huawei.com
If I try and email you
On 18 October 2013 14:02, Masami Hiramatsu
wrote:
> (2013/10/17 20:17), Sandeepa Prabhu wrote:
>> This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
>> and return probes(kretprobes) support for ARM64.
>>
>> Kprobes mechanism make use of sof
On 18 October 2013 14:02, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2013/10/17 20:17), Sandeepa Prabhu wrote:
This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
and return probes(kretprobes) support for ARM64.
Kprobes mechanism make use of software
ry.S: do_dbg to route
software breakpoint (BRK64) exception to do_debug_exception()
Signed-off-by: Sandeepa Prabhu
Signed-off-by: Deepak Saxena
---
arch/arm64/include/asm/debug-monitors.h | 21
arch/arm64/kernel/debug-monitors.c | 86 -
arch/arm64/ke
the condition fields
of opcode, the instruction is effectively NOP. Kprobes consider
this case as 'miss'.
Signed-off-by: Sandeepa Prabhu
---
arch/arm64/kernel/Makefile| 3 +-
arch/arm64/kernel/condn-helpers.c | 120 +
arch/arm64/kernel/kprobes-arm64.c | 120
Add info prints in sample kprobe handlers for ARM and ARM64
architecture.
Signed-off-by: Sandeepa Prabhu
---
samples/kprobes/kprobe_example.c | 16
1 file changed, 16 insertions(+)
diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
index 366db1a
and restore original return address in ELR_EL1,
this way, saved pt_regs still hold the original register context to be
carried back to the probed kernel function.
Signed-off-by: Sandeepa Prabhu
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/kprobes.h | 1 +
arch/arm64/include
ight now.
System instructions are mostly enabled for stepping, except MSR
immediate that update "daif" flags in PSTATE, which are not safe
for probing(rejected)
Signed-off-by: Sandeepa Prabhu
---
arch/arm64/Kconfig| 1 +
arch/arm64/include/asm/kprobes.h | 59 +++
This patch enables kprobes support in arm64 common defconfig
file.
Signed-off-by: Sandeepa Prabhu
---
arch/arm64/configs/defconfig | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 31c81e9
ted on ARM v8 fast model with sample modules from: samples/kprobes/
Sandeepa Prabhu (6):
arm64: support single-step and breakpoint handler hooks
arm64: Kprobes with single stepping support
arm64: Kprobes instruction simulation support
arm64: Add kernel return probes support(kretprobes)
ar
on ARM v8 fast model with sample modules from: samples/kprobes/
Sandeepa Prabhu (6):
arm64: support single-step and breakpoint handler hooks
arm64: Kprobes with single stepping support
arm64: Kprobes instruction simulation support
arm64: Add kernel return probes support(kretprobes)
arm64
now.
System instructions are mostly enabled for stepping, except MSR
immediate that update daif flags in PSTATE, which are not safe
for probing(rejected)
Signed-off-by: Sandeepa Prabhu sandeepa.pra...@linaro.org
---
arch/arm64/Kconfig| 1 +
arch/arm64/include/asm/kprobes.h
This patch enables kprobes support in arm64 common defconfig
file.
Signed-off-by: Sandeepa Prabhu sandeepa.pra...@linaro.org
---
arch/arm64/configs/defconfig | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64
Add info prints in sample kprobe handlers for ARM and ARM64
architecture.
Signed-off-by: Sandeepa Prabhu sandeepa.pra...@linaro.org
---
samples/kprobes/kprobe_example.c | 16
1 file changed, 16 insertions(+)
diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes
and restore original return address in ELR_EL1,
this way, saved pt_regs still hold the original register context to be
carried back to the probed kernel function.
Signed-off-by: Sandeepa Prabhu sandeepa.pra...@linaro.org
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/kprobes.h
the condition fields
of opcode, the instruction is effectively NOP. Kprobes consider
this case as 'miss'.
Signed-off-by: Sandeepa Prabhu sandeepa.pra...@linaro.org
---
arch/arm64/kernel/Makefile| 3 +-
arch/arm64/kernel/condn-helpers.c | 120 +
arch/arm64/kernel
: do_dbg to route
software breakpoint (BRK64) exception to do_debug_exception()
Signed-off-by: Sandeepa Prabhu sandeepa.pra...@linaro.org
Signed-off-by: Deepak Saxena dsax...@linaro.org
---
arch/arm64/include/asm/debug-monitors.h | 21
arch/arm64/kernel/debug-monitors.c | 86
On 27 September 2013 21:11, Jiang Liu wrote:
> On 09/25/2013 10:35 PM, Sandeepa Prabhu wrote:
>> On 25 September 2013 16:14, Jiang Liu wrote:
>>> From: Jiang Liu
>>>
>>> Introduce aarch64_insn_patch_text() and __aarch64_insn_patch_text()
>>> to p
On 27 September 2013 21:11, Jiang Liu liu...@gmail.com wrote:
On 09/25/2013 10:35 PM, Sandeepa Prabhu wrote:
On 25 September 2013 16:14, Jiang Liu liu...@gmail.com wrote:
From: Jiang Liu jiang@huawei.com
Introduce aarch64_insn_patch_text() and __aarch64_insn_patch_text()
to patch kernel
our requirement.
> Thanks!
Hi Jiang,
Thanks. please CC me when you post next version of this patch, then I
can rebase my code and verify it.
Thanks,
Sandeepa
>
> On 09/25/2013 10:35 PM, Sandeepa Prabhu wrote:
>> On 25 September 2013 16:14, Jiang Liu wrote:
>>> From: Jiang Liu
&g
On 25 September 2013 20:46, Steven Rostedt wrote:
> On Wed, 25 Sep 2013 20:12:17 +0530
> Sandeepa Prabhu wrote:
>
>
>> > On aarch64, are instructions always word aligned? If not, it should be
>> > safe for stop machine to modify non word aligned instructions,
On 25 September 2013 20:05, Steven Rostedt wrote:
> On Wed, 25 Sep 2013 18:44:22 +0800
> Jiang Liu wrote:
>> diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
>> index 8541c3a..50facfc 100644
>> --- a/arch/arm64/kernel/insn.c
>> +++ b/arch/arm64/kernel/insn.c
>> @@ -15,6 +15,8 @@
On 25 September 2013 16:14, Jiang Liu wrote:
> From: Jiang Liu
>
> Introduce aarch64_insn_patch_text() and __aarch64_insn_patch_text()
> to patch kernel and module code.
>
> Function aarch64_insn_patch_text() is a heavy version which may use
> stop_machine() to serialize all online CPUs, and
On 25 September 2013 16:14, Jiang Liu liu...@gmail.com wrote:
From: Jiang Liu jiang@huawei.com
Introduce aarch64_insn_patch_text() and __aarch64_insn_patch_text()
to patch kernel and module code.
Function aarch64_insn_patch_text() is a heavy version which may use
stop_machine() to
On 25 September 2013 20:05, Steven Rostedt rost...@goodmis.org wrote:
On Wed, 25 Sep 2013 18:44:22 +0800
Jiang Liu liu...@gmail.com wrote:
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 8541c3a..50facfc 100644
--- a/arch/arm64/kernel/insn.c
+++
On 25 September 2013 20:46, Steven Rostedt rost...@goodmis.org wrote:
On Wed, 25 Sep 2013 20:12:17 +0530
Sandeepa Prabhu sandeepa.pra...@linaro.org wrote:
On aarch64, are instructions always word aligned? If not, it should be
safe for stop machine to modify non word aligned instructions
.
Thanks!
Hi Jiang,
Thanks. please CC me when you post next version of this patch, then I
can rebase my code and verify it.
Thanks,
Sandeepa
On 09/25/2013 10:35 PM, Sandeepa Prabhu wrote:
On 25 September 2013 16:14, Jiang Liu liu...@gmail.com wrote:
From: Jiang Liu jiang@huawei.com
88 matches
Mail list logo
