[PATCH v12 7/7] ARM: kprobes: enable OPTPROBES for ARM 32

On Fri, 2014-12-05 at 11:38 +0800, Wang Nan wrote:

On 2014/12/5 0:21, Jon Medhurst (Tixy) wrote:

quoted

On Thu, 2014-12-04 at 13:36 +0800, Wang Nan wrote:

[trim some text]

quoted

I have retested this patch and on one of the arm test cases I get an
undefined instruction exception in kprobe_arm_test_cases. When this
happens PC points to the second nop below. 


80028a38:	e320f000 	nop	{0}
80028a3c:	e11000b2 	ldrh	r0, [r0, -r2]
80028a40:	e320f000 	nop	{0}

As all three instructions will have probes on them during testing, and
un-optimised probes are implemented by using an undefined instruction to
act as a breakpoint, my first thought was that we have a race condition
somewhere with adding, removing or optimizing probes. Though a reboot a
retest failed in the same way on the same instruction, so I'm not 100%
convinced about strictly timing related bugs.
 

Does the problem appear in your platform in each time?

Three times out of three tries yes. Though the third try was built
differently and the problem occurred on a different test case.

 Currently I have only
QEMU machine for testing and haven't seen problem like this before.

I don't know much about QEMU and have never used it, but I'm assuming
QEMU doesn't make any attempt to simulate caches like the data cache,
instruction cache, TLBs, branch predictor? Does it even emulate multiple
CPUs with multiple host CPU threads? Basically, I very much doubt QEMU
is a very good test of kernel code in general, and especially code that
modifies code and has multiple cpus running in parallel.

Do you not have access to any kind of ARM board to try some testing on?

 Could
you please provide a detail steps for me to reproduce it? Or do you just
enable kprobe test code when booting and this exception simply appear twice?

I applied the patches on top of Linux 3.18-rc5 and set VERBOSE in
arm/probes/kprobes/test-core.h to 1. Then built a kernel configured
using vexpress_defconfig and enabled

CONFIG_KPROBES=y
CONFIG_ARM_KPROBES_TEST=y
CONFIG_DEBUG_INFO=y

then booted on a Versatile Express board with a TC2 CoreTile (A15/A7
big.LITTLE CPU).

The Oops I described happened on two consecutive boots of the board. I
then tried again setting VERBOSE to 0 and I got a similar OOPs but on a
different test case.

I'm worried because this whole optimised kprobes has some rather
complicated interactions, e.g. can the background thread that changes
breakpoints to jumps (or back again?) could occur at the same time
another CPU is processing a kprobe that's been hit, or is in the process
of removing a probe.

-- 
Tixy