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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Thu, Oct 22, 2026 at 03:33:16PM -0400, Liam R. Howlett wrote:
> On 26/10/22 07:56PM, Jann Horn wrote:
> > On Thu, Oct 22, 2026 at 3:57 AM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> 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).

But you'd still get the WARN_ON() in the 'does not matter' case right?

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

Fatal signals too?

Might be some other cases too there.

In general I'd say this WARN_ON() is probably not helpful.

--
Cheers, Lorenzo