On 26/10/22 07:56PM, Jann Horn wrote: > On Thu, Oct 22, 2026 at 3:57 AM Alexei Starovoitov > <[email protected]> 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
