On Tue, 18 Feb 2020 12:04:41 +0100
Christophe Leroy <christophe.leroy@xxxxxx> wrote:
Nevertheless, if one symbol has been forgotten in the blacklist, I think
it is a problem if it generate Oopses.
There is a long history also on x86 to make a blacklist. Anyway, how did
you get this error on PPC32? Somewhere would you like to probe and
it is a real mode function? Or, it happened unexpectedly?
The first Oops I got was triggered by a WARN_ON() kind of trap in real
mode. The trap exception handler called kprobe_handler() which tried to
read the instruction at the trap address (which was a real-mode address)
so it triggered a Bad Access Fault.
This was initially the purpose of my patch.
OK, then filtering the trap reason in kprobe handler is a bit strange.
It should be done in the previous stage (maybe in trap.c)
Can we filter it by exception flag or only by checking the instruction
which causes the exception, or needs get_kprobe()...?
After discussion with you, I started looking at what would be the effect
of setting a kprobe event in a function which runs in real mode.
If the kprobe single-stepping (or emulation) works in real mode, just
ignore the kprobes pre/post_handlers and increment nmissed count.
If that doesn't work, we have to call a BUG_ON, because we can not
continue the code execution. And also, you have to find a way to make
a blacklist for real mode code.