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