Re: [PATCH] powerpc/kprobes: Fix trap address when trap happened in real mode

From: Christophe Leroy
Date: Tue Feb 18 2020 - 08:58:05 EST

Le 18/02/2020 Ã 13:33, Masami Hiramatsu a ÃcritÂ:
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)

See commit

Can we filter it by exception flag or only by checking the instruction
which causes the exception, or needs get_kprobe()...?

The trap instruction used by kprobe is also used for other purposes like BUG_ON() or WARN_ON(), so 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.

Yes, it has to be done function by function (hoppefully there's not more than a dozen).
But I'd like something which can fails gracefully for the functions we will forget to mark noprobe.

But as a first step I'd really like a bug fix in 5.6 to avoid Oopsing in kprobe_handler() at a non-kprobe trap.