Re: [PATCH bpf-next 4/9] uprobes/x86: Don't WARN if an optimized probe can't be written

[Liam R. Howlett]

On 26/10/22 07:56PM, Jann Horn wrote:
> On Thu, Oct 22, 2026 at 3:57 AM Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx> wrote:
> > @@ -1197,7 +1194,7 @@ static int __arch_uprobe_optimize(struct arch_uprobe *auprobe, struct mm_struct
> >         if (IS_ERR(tramp))
> >                 return PTR_ERR(tramp);
> >         ret = swbp_optimize(auprobe, vma, vaddr, tramp->vm_start);
> > -       if (WARN_ON_ONCE(ret) && new_mapping)
> > +       if (ret && new_mapping)
> >                 WARN_ON_ONCE(do_munmap(mm, tramp->vm_start, PAGE_SIZE, NULL));
> 
> Not an issue with your patch, just FYI regarding this preexisting
> WARN_ON_ONCE():
> A failing small GFP_KERNEL allocation could theoretically cause
> do_munmap() to fail; the VMA tree has the ugly quirk that you can't
> reliably _remove_ elements without memory allocation.

During munmap() we may need an allocation of one or two vma(s)
(splitting a vma or punching a hole) - and those may have anon vma
chains that need to be allocated, we may need to allocate for uffd
reasons, and we may need to allocate for the maple tree.

That said, this path exclusively uses GFP_KERNEL which means we will
invoke the shrinker.  If the shrinker comes back unsuccessful, we will
invoke OOM.  This either succeed or it does not matter (we'll kill this
task).

The other two possibilities is that the OOM is disabled during
hibernate/suspend calls, or error injection caused the failure.

Thanks,
Liam