Re: [PATCH 2/2] x86/entry: Fix unwinding from kprobe on PUSH/POP instruction

From: Josh Poimboeuf
Date: Thu Feb 16 2023 - 11:58:45 EST


On Thu, Feb 16, 2023 at 11:35:19PM +0900, Masami Hiramatsu wrote:
> > It could be I'm just confusing things... when #DB traps it is actually
> > because the instruction is complete, so looking up the ORC based on the
> > next instruction is correct, while when #DB faults, it is because the
> > instruction has not yet completed and again ORC lookup on IP just works.
> >
> > So while determining if #DB is trap or fault is a giant pain in the
> > arse, it does not actually matter for the unwinder in this case.
> >
> > And with the INT3 thing the problem is that we've replaced an
> > instruction that was supposed to do a stack op.
> >
>
> If the kprobe checks whether the original instruction do a stack op and
> if so, setting a flag on current_kprobe will help unwinder finds that case?
>
> Of course all INT3 user may need to do this but it should be limited.

No, for INT3, even if the original instruction wasn't a stack op, we can
treat it the same way. Either way, we know the instruction hasn't
executed so we can still use that address to look up the ORC entry.

--
Josh