On Wed, May 27, 2026 at 11:58:52AM +0200, Jiri Olsa wrote: SNIP
> > Although the old destroy_uprobe_trampoline only freed the struct (not the > > underlying VMA), the new code appears to introduce a VMA leak: the freshly > > mapped PAGE_SIZE special mapping in the user's address space stays mapped > > even though optimization failed. arch_uprobe_optimize() then sets > > ARCH_UPROBE_FLAG_OPTIMIZE_FAIL so subsequent calls won't retry, leaving the > > orphan trampoline mapping in the address space until exit_mmap() reaps it at > > process teardown. > > > > The commit message mentions: "Note the original code called > > destroy_uprobe_trampoline if the optimiation failed, but it only freed the > > struct uprobe_trampoline object, not the vma. The new vma leak is fixed in > > following change." > > > > Is the VMA leak addressed in the subsequent commit in this series? > > yes, in: > > [1] uprobes/x86: Unmap trampoline vma object in case it's unused > > > > > A secondary behaviour change is that 'return > > WARN_ON_ONCE(swbp_optimize(...))' > > now returns the boolean truth value of the error (0 or 1) instead of the > > original errno. While the current caller (arch_uprobe_optimize) only treats > > the value as boolean, could this surprise a future caller that propagates > > the > > return code? > > ah ok, this is actualy 'fixed' in [1] above, but yea we should > fix that directly in this change, will do nah, it's ok, the caller does not care about the exact error value, just 0 or 1 is fine jirka
