Re: [PATCHv4 02/13] uprobes/x86: Remove struct uprobe_trampoline object

[Jiri Olsa <olsajiri@gmail.com>]

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