Kprobes for PPC32[Booke]

rsmadhvesh at vsnl.net rsmadhvesh at vsnl.net
Fri Mar 16 02:41:27 EST 2007


Hi,

This is regarding the kprobes support for ppc32 with
BOOKE versions. The attached patch contains this code 
and there is seperate patch which includes some kernel 
modules to test the same. This is tested for ebony 
platform(ppc440_gp).

Kernel Version: 2.6.16.39
Platform: Ebony

But there are some issues which i have noticed while
handling debug exception used for single step operation. 

1. The single step operation in PPC32 is implemented using
debug control register (DBCR) which can be used to generate
single step debug exception. 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
debug 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 of enabling interrupts while processing kprobes?

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. Can somebody review this
and provide some inputs for this code?

(Note:After porting the above patches to 2.6.20, the same above results
are noticed!)


Best Regards
Madhvesh

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: kprobes-ppc-2.6.16.39-20070313.patch
Type: application/octet-stream
Size: 22227 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20070315/63e79eb2/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kprobes-kernel-test-module-20070313.patch
Type: application/octet-stream
Size: 41816 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20070315/63e79eb2/attachment-0001.obj>


More information about the Linuxppc-dev mailing list