On Fri, May 22, 2026 at 11:50:54AM -0700, Andrii Nakryiko wrote: > On Thu, May 21, 2026 at 5:44 AM Jiri Olsa <[email protected]> wrote: > > > > When we do fork or clone without CLONE_VM the new process won't > > have uprobe trampoline vma objects and at the same time it will > > have optimized code calling that trampoline and crash. > > > > Fixing this by allowing vma uprobe trampoline objects to be copied > > on fork to the new process. > > > > Fixes: ba2bfc97b462 ("uprobes/x86: Add support to optimize uprobes") > > Signed-off-by: Jiri Olsa <[email protected]> > > --- > > arch/x86/kernel/uprobes.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c > > index 6824376e253d..11ec6b89b135 100644 > > --- a/arch/x86/kernel/uprobes.c > > +++ b/arch/x86/kernel/uprobes.c > > @@ -701,7 +701,7 @@ static struct vm_area_struct > > *get_uprobe_trampoline(unsigned long vaddr) > > return ERR_PTR(vaddr); > > > > return _install_special_mapping(current->mm, vaddr, PAGE_SIZE, > > - > > VM_READ|VM_EXEC|VM_MAYEXEC|VM_MAYREAD|VM_DONTCOPY|VM_IO, > > + VM_READ|VM_EXEC|VM_MAYEXEC|VM_MAYREAD|VM_IO, > > so on fork we'll get sys_uprobe invocations which will go into uprobe > trampoline and syscall will just keep returning -EPROTO, is that > right?
so the child gets the inherited optimized call path.and now also the trampoline, which executes the uprobe syscall and so if there's related uprobe it will be processed -EPROTO is returned for uprobe syscall executed out of uprobe trampoline > > what would happen in the similar situation for process with int3 > uprobe being forked/cloned? Will it inherit int3 as well, and then > will keep hitting interrupts that would just do nothing? > > is there a way to restore original memory page for clones? this > behavior (unless I'm misunderstanding) seems suboptimal > performance-wise the standard uprobes seem to handle this situation by removing the brekpoint from current->mm, if the uprobe->handler returns UPROBE_HANDLER_REMOVE (for all uprobe consumers) .. and the uprobe->handler does current->mm filter first in uprobe_perf_func and returns UPROBE_HANDLER_REMOVE in case it does not match this works also for optimized uprobes on top of standard uprobes but we don't do that for uprobe_multi and I think we could do something similar, the code is there, perhaps we just need to add the filter jirka
