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 > > <[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).
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
