kprobes support for ppc32{BOOKE]

[rsmadhvesh at vsnl dot net]

Hi All,

This is regarding the kprobes support for ppc32 with
BOOKE versions. We have finished implementation
for this and it is tested for ebony platform(ppc440_gp).

Kernel Version: 2.6.16.39
Platform: Ebony

Most of the code is derived from powerpc arch and Booke
special registers (debug exception) are used in implementing
kprobes for ppc_44x.  The attached patch contains this code and 
there is seperate patch which includes some kernel modules to 
test the same.

But there are some interesting topics which i would like to
discuss when compared to our earlier implementation for
ARM and MIPS kprobes support.

1. In PPC32, there is a support for single step operation using
debug control register (DBCR) which can be used to generate
single step debug exception. So this mechanism is used in handling
post handler execution of kprobes (see code prepare_single_step)

2. It was noticed that having preempt_disable() at the beginning of
kprobe_handler, generates OOPS and kprobes doesnot work. But this is 
against the original kprobes design implemented in other already working 
archs (that is, preemption is disabled for the entire duration of pre and post
handlers execution). The basic problem noticed is, change in the preempt
count after generating single step exception. Even though the preemption
is disabled at the beginning of kprobe_handler(), after generating the
single step exception, preempt count gets printed as zero in DebugException() 
handler of traps.c. This causes the problem and system generates OOPS!!

To resolve this problem, we have introduced the preempt_disable 
and preempt_enable_no_resched blocks in pre and post handlers
exceptions switch case of kprobe_exceptions_notify(), and by this way 
we found that the preempt count is consistent and pre and post handlers 
get executed. So why in PPC32 arch, preempt count gets changed between the
exceptions? Is this problem already noticed or is it because of some other
bug in the kprobes code of the attached patch?


3. In PPC32 it is noticed that interrupts are enabled by default and 
initially i had suspected this as the cause for problem stated in <2>.
But it is found that by disabling interrupts, uncommenting the #if 0 blocks
in the attached patch, the same problem appears. But this code is still
not tested for kprobes reentrancy (by having interrupts enabled). Does 
anybody see a issue with respect to this of having all interrupts enabled?

4. While executing the fault handler using the test k-004.c in the 
attached patch, we noticed the following message being printed
repeatedly for every pre handler execution where put_user() gets
called to generate fault exception.

Debug: sleeping function called from invalid context at /..../k-004.c:39
in_atomic():1, irqs_disabled():1

Even though interrupts are enabled in the code(MSR bits show it as 
enabled), why the above debug message shows it as disabled? 
It appears that put_user() will  internally call might_sleep() which 
turns out to be a sleeping function. But this same test didnot report 
any kind of above message while testing with ARM and MIPS arch 
even though all interrupts were disabled explicitly. So is it a failure
message ? or wrongly printed only in ppc32? After getting this message,
the test completes and the system is stable!!! 

Since this code is implemented with limited ppc32 arch knowledge,
some key things may be missing in this. Review comments for the
above patches are welcome...

(After testing the above patches for 2.6.20, the same above results
are noticed!)


Best Regards
Madhvesh

==================
Madhvesh. R. Sulibhavi
Sony India Software Centre
Bangalore

Attachment: kprobes-ppc-2.6.16.39-20070313.patch
Description: Binary data

Attachment: kprobes-kernel-test-module-20070313.patch
Description: Binary data