Messages in this thread | | | Date | Thu, 16 Feb 2023 08:58:36 -0800 | From | Josh Poimboeuf <> | Subject | Re: [PATCH 2/2] x86/entry: Fix unwinding from kprobe on PUSH/POP instruction |
| |
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
| |