On Mon, Aug 27, 2018 at 11:56 AM, Jann Horn <ja...@google.com> wrote: > This removes the call into exception fixup that was added in > commit c28f896634f2 ("[PATCH] kprobes: fix broken fault handling for > x86_64"). > > On X86, kprobe_fault_handler() is called from two places: > do_general_protection() (for #GP) and kprobes_fault() (for #PF). > In both paths, the fixup_exception() call in the kprobe fault handler is > redundant. > > For #GP, fixup_exception() is called immediately before > kprobe_fault_handler() is invoked - if someone wanted to fix up our #GP, > they've already done so, no need to try again. (This assumes that the > kprobe's fault handler isn't going to do something crazy like changing RIP > so that it suddenly points to an instruction that does userspace access.)
This needs review by someone who understands kprobes better than I do. What happens if someone puts a kprobe on a uaccess instruction and the uaccess subsequently faults? > > For #PF on a kernel address from kernel space, after the kprobe fault > handler has run, we'll go into no_context(), which calls fixup_exception(). > > Signed-off-by: Jann Horn <ja...@google.com> > --- > arch/x86/kernel/kprobes/core.c | 7 ------- > 1 file changed, 7 deletions(-) > > diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c > index 467ac22691b0..7315ac202aad 100644 > --- a/arch/x86/kernel/kprobes/core.c > +++ b/arch/x86/kernel/kprobes/core.c > @@ -1021,13 +1021,6 @@ int kprobe_fault_handler(struct pt_regs *regs, int > trapnr) > if (cur->fault_handler && cur->fault_handler(cur, regs, > trapnr)) > return 1; > > - /* > - * In case the user-specified fault handler returned > - * zero, try to fix up. > - */ > - if (fixup_exception(regs, trapnr)) > - return 1; > - > /* fixup routine could not handle it. */ > } > > -- > 2.19.0.rc0.228.g281dcd1b4d0-goog >