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? 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 > &tramp_mapping); > } > > -- > 2.53.0 >
