Kernel patch series stops uprobes from stalling every fork()

Alexei Starovoitov has posted a nine-patch series for bpf-next that stops uprobe registration and unregistration from stalling every fork() on the system whenever any process holds its mmap lock busy.

The problem showed up in production. Uprobes were attached to libraries and binaries mapped by many processes across large fleets. On some hosts, every fork waited for minutes while a probe was being registered, even when the busy process did not map the probed file. Registration walked every relevant address space under a write-side fork lock and slept on each mmap lock; concurrent forks held the matching read side and piled up behind that sleep.

The core changes avoid sleeping on mmap lock while holding the fork serialization lock, and the reverse. Busy address spaces are deferred and finished after the fork lock is dropped. Children that fork mid-walk get the same breakpoint install or remove work their parent would have received, so inherited probes stay consistent.

The series also closes related bugs the new path makes easier to hit. On x86, half-finished optimized probes no longer trigger warnings when a write fails because the task is being killed or memory is tight. Inherited perf events no longer lose their child's breakpoint when another consumer of the same uprobe comes and goes. A tracer killed mid-unregister no longer leaves breakpoints behind forever; removal is finished from a workqueue that cannot be interrupted by fatal signals.

Benchmarks on a 32-CPU VM show the longest concurrent fork dropping from roughly 200 to 420 milliseconds down to well under a millisecond in the contended cases, while attach times stay comparable. A new BPF selftest exercises attach and detach against a process that holds mmap lock via MADV_POPULATE_READ and checks that other forks proceed and that children keep matching breakpoints.

The work matters for any production tracing or BPF tooling that attaches uprobes to widely shared userspace, where fork latency is a system-wide property rather than a local one.