[PATCH bpf-next 0/9] uprobes: Don't stall fork() when mmap_lock is busy · Alexei Starovoitov <hidden> · 2026-10-22
[PATCH bpf-next 1/9] mm: Bring back mmap_write_trylock() · Alexei Starovoitov <hidden> · 2026-10-22
[PATCH bpf-next 2/9] uprobes: Don't run exit_mmap() under dup_mmap_sem · Alexei Starovoitov <hidden> · 2026-10-22
[PATCH bpf-next 3/9] uprobes/x86: Finish an unoptimization which failed half-way · Alexei Starovoitov <hidden> · 2026-10-22
Re: [PATCH bpf-next 3/9] uprobes/x86: Finish an unoptimization which failed half-way · Gregory Price (Meta) <gourry@gourry.net> · 2026-10-22
Re: [PATCH bpf-next 3/9] uprobes/x86: Finish an unoptimization which failed half-way · Jiri Olsa <hidden> · 2026-10-23
[PATCH bpf-next 4/9] uprobes/x86: Don't WARN if an optimized probe can't be written · Alexei Starovoitov <hidden> · 2026-10-22
Re: [PATCH bpf-next 4/9] uprobes/x86: Don't WARN if an optimized probe can't be written · bot+bpf-ci@kernel.org · 2026-10-22
Re: [PATCH bpf-next 4/9] uprobes/x86: Don't WARN if an optimized probe can't be written · Jann Horn <jannh@google.com> · 2026-10-22
Re: [PATCH bpf-next 4/9] uprobes/x86: Don't WARN if an optimized probe can't be written · Liam R. Howlett <liam@infradead.org> · 2026-10-22
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> · 2026-10-23
Re: [PATCH bpf-next 4/9] uprobes/x86: Don't WARN if an optimized probe can't be written · Jiri Olsa <hidden> · 2026-10-23
[PATCH bpf-next 5/9] uprobes: Don't sleep on mmap_lock under dup_mmap_sem · Alexei Starovoitov <hidden> · 2026-10-22
Re: [PATCH bpf-next 5/9] uprobes: Don't sleep on mmap_lock under dup_mmap_sem · bot+bpf-ci@kernel.org · 2026-10-22
Re: [PATCH bpf-next 5/9] uprobes: Don't sleep on mmap_lock under dup_mmap_sem · Andrii Nakryiko <hidden> · 2026-10-22
[PATCH bpf-next 6/9] uprobes: Don't sleep on mmap_lock with dup_mmap_sem held in dup_mmap() · Alexei Starovoitov <hidden> · 2026-10-22
Re: [PATCH bpf-next 6/9] uprobes: Don't sleep on mmap_lock with dup_mmap_sem held in dup_mmap() · Jann Horn <jannh@google.com> · 2026-10-22
Re: [PATCH bpf-next 6/9] uprobes: Don't sleep on mmap_lock with dup_mmap_sem held in dup_mmap() · David Hildenbrand (Arm) <david@kernel.org> · 2026-10-23
Re: [PATCH bpf-next 6/9] uprobes: Don't sleep on mmap_lock with dup_mmap_sem held in dup_mmap() · Lorenzo Stoakes (ARM) <ljs@kernel.org> · 2026-10-27
[PATCH bpf-next 7/9] fork: Let the new task point to its mm before uprobes can find it · Alexei Starovoitov <hidden> · 2026-10-22
Re: [PATCH bpf-next 7/9] fork: Let the new task point to its mm before uprobes can find it · sashiko-bot@kernel.org · 2026-10-22
Re: [PATCH bpf-next 7/9] fork: Let the new task point to its mm before uprobes can find it · Lorenzo Stoakes (ARM) <ljs@kernel.org> · 2026-10-27
[PATCH bpf-next 8/9] uprobes: Don't leak the breakpoints if the unregistering task is killed · Alexei Starovoitov <hidden> · 2026-10-22
Re: [PATCH bpf-next 8/9] uprobes: Don't leak the breakpoints if the unregistering task is killed · sashiko-bot@kernel.org · 2026-10-22
[PATCH bpf-next 9/9] selftests/bpf: Test uprobes and fork() with busy mmap_lock · Alexei Starovoitov <hidden> · 2026-10-22
Re: [PATCH bpf-next 9/9] selftests/bpf: Test uprobes and fork() with busy mmap_lock · sashiko-bot@kernel.org · 2026-10-22
Re: [PATCH bpf-next 9/9] selftests/bpf: Test uprobes and fork() with busy mmap_lock · Alexei Starovoitov <hidden> · 2026-10-22
Re: [PATCH bpf-next 9/9] selftests/bpf: Test uprobes and fork() with busy mmap_lock · bot+bpf-ci@kernel.org · 2026-10-22

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

From: Jann Horn <jannh@google.com>
Date: 2026-10-22 17:56:59
Also in: bpf, linux-mm, linux-perf-users, lkml

On Thu, Oct 22, 2026 at 3:57 AM Alexei Starovoitov
[off-list ref] wrote:

quoted hunk ↗ jump to hunk

@@ -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.

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help