Re: [PATCH] uprobes: Skip breakpoint installation on non executable vmas

On Wed, Aug 05, 2026 at 10:29:13AM -0700, Andrii Nakryiko wrote:

On Wed, Aug 5, 2026 at 8:14 AM Oleg Nesterov [off-list ref] wrote:

quoted

On 08/05, Sumanth Korikkar wrote:

quoted

bpftrace  -e 'usdt:./testprogs/usdt_semaphore_test:tracetest:testprobe {
printf("%s\n", str(arg1) ); exit(); }'

does bpftrace care if USDT semaphore is set to 1 or 2, it shouldn't.
As long as detaching decrements it from 2 back to zero we should be
fine. Is that what's happening? If so, is there really a problem
needing to be fixed?

USDT spec mentions the following:
https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
 
If a semaphore is associated with a probe, it will be of type unsigned
short. A semaphore may gate invocations of a probe; it must be set to a
non-zero value to guarantee that the probe will be hit. "Semaphores are
treated as a counter"; your tool should increment the semaphore to enable
it, and decrement the semaphore when finished.
 
I do not know, if any application checks for exact value of 1
instead of semaphore > 0 check.

As suggested by Andrii and Oleg earlier - "uprobe_write() creates
the COW'ed anonymous page, so the 1st install_breakpoint() won't affect
the 2nd mapping to the same binary"

To me, the following looks like a valid point to consider the fix:
Installing a breakpoint on a non executable relro mapping is not useful
because instructions are not executed on it. Anonymous COW page sits
in memory untouched and memory is wasted.

quoted

I am hoping that Andrii and Jiri (cc'ed) can take a look, I know nothing
about usdt... And TBH, I don't even know what RELRO is ;)

Let me ask a couple of questions for now.

quoted

expects a semaphore increment of 1, but semaphore gets double incremented

Test program:
https://github.com/bpftrace/bpftrace/blob/master/tests/testprogs/usdt_semaphore_test.c

Perhaps you can provide the test-case which I could compile on my
machine without libbpf-usdt/usdt.h?

And can you explain what the bpftrace cmd above actually does? I mean,
where does it put the uprobe? I guess the ref_ctr_offset argument of
uprobe_register() refers to USDT_DEFINE_SEMA() in that test-case...

quoted

Reason: .text mapping and RELRO mapping resolve to the same page aligned
file offset 0
01000000-01001000 r-xp 00000000 5e:01 usdt_semaphore_test (.text)
01001000-01002000 r--p 00000000 5e:01 usdt_semaphore_test (RELRO)
01002000-01003000 rw-p 00001000 5e:01 usdt_semaphore_test (semaphore)

valid_vma() currently accepts both mappings (which contains executable
text and RELRO mapping) during uprobe registration, since both have
VM_MAYEXEC set. This causes register_for_each_vma() to call
install_breakpoint() twice for the same underlying uprobe offset in the
process.  This means, update_ref_ctr() is called twice for the same
process, so a usdt semaphore is incremented from 0 to 2.

So, 2 vmas map the same binary, install_breakpoint() is called twice.
But, the 2nd install_breakpoint() -> ... -> uprobe_write() should see
that the original insn was already replaced by int3, in this case
verify_opcode() returns 0 and uprobe_write() should do nothing.

And, if this uprobe was optimized before the 2nd install_breakpoint(),
uprobe_write() won't be called.

Hmm.

Even though it's the same file offset, it is mapped to two different
virtual addresses, so I think it should be two different memory pages
that will have two separate int3 instructions. I don't think there is
any contradiction or surprise, is there?

True. cross checked the behaviour with bpftrace stacktrace. Pasted the
output in previous thread.

quoted

quoted

Installing a breakpoint for mapping without VM_EXEC and
updating usdt reference counter in that case is not useful.

Skip non VM_EXEC mappings in install_breakpoint(). This fixes semaphore
double increment as shown in the above usecase.

You said that mapping is VM_MAYEXEC, which means that kernel allows to
re-mmap it as executable, if that happens, we will miss uprobe in that
location, so that's probably why breakpoint is installed for
VM_MAYEXEC.

True. 
ref commit 78a320542e6c ("uprobes: Change valid_vma() to demand
VM_MAYEXEC rather than VM_EXEC")

Thank you