On Tue, Sep 16, 2025 at 03:28:52PM -0700, Andrii Nakryiko wrote: > On Tue, Sep 16, 2025 at 2:53 PM Jiri Olsa <[email protected]> wrote: > > > > If uprobe handler changes instruction pointer we still execute single > > step) or emulate the original instruction and increment the (new) ip > > with its length. > > > > This makes the new instruction pointer bogus and application will > > likely crash on illegal instruction execution. > > > > If user decided to take execution elsewhere, it makes little sense > > to execute the original instruction, so let's skip it. > > > > Acked-by: Oleg Nesterov <[email protected]> > > Acked-by: Andrii Nakryiko <[email protected]> > > Signed-off-by: Jiri Olsa <[email protected]> > > --- > > kernel/events/uprobes.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c > > index 7ca1940607bd..2b32c32bcb77 100644 > > --- a/kernel/events/uprobes.c > > +++ b/kernel/events/uprobes.c > > @@ -2741,6 +2741,13 @@ static void handle_swbp(struct pt_regs *regs) > > > > handler_chain(uprobe, regs); > > > > + /* > > + * If user decided to take execution elsewhere, it makes little > > sense > > + * to execute the original instruction, so let's skip it. > > + */ > > + if (instruction_pointer(regs) != bp_vaddr) > > + goto out; > > + > > Peter, Ingo, > > Are you guys ok with us routing this through the bpf-next tree? We'll > have a tiny conflict because in perf/core branch there is > arch_uprobe_optimize() call added after handler_chain(), so git merge > will be a bit confused, probably. But it should be trivially > resolvable.
Nah, I suppose that'll be fine. Thanks!
