On Thu, Apr 30, 2026 at 05:22:18PM +0200, Jann Horn wrote: > On Wed, Apr 29, 2026 at 11:11 PM Daniel Walker (danielwa) > <[email protected]> wrote: > > On Wed, Apr 29, 2026 at 05:24:25PM +0200, Oleg Nesterov wrote: > > > On 04/29, David Hildenbrand (Arm) wrote: > > > > > > > > On 4/29/26 15:15, Darko Tominac wrote: > > > > > > > > > uprobe infrastructure does not re-instrument pages on individual page > > > > > faults (uprobe_mmap() is only called during VMA creation, not on > > > > > page-in), the breakpoints are silently lost once the discarded pages > > > > > are > > > > > re-read from the backing file. The probes stop firing with no error > > > > > indication, and the only recovery is to unregister and re-register the > > > > > affected uprobes. > > > > > > > > Right. Don't MADV_DONTNEED uprobes, just like you are not supposed to > > > > MADV_DONTNEED debugger breakpoints/set data etc. :) > > > > > > Agreed, thanks. > > > > > > Shouldn't there be some sort of compensation or notification for this, or > > is each person that > > hits this suppose to just scratch their head and send a patch that's > > rejected? > > I guess we could add a pr_warn_once() that warns when > madvise(MADV_DONTNEED) is called on a read+execute file mapping, > and/or (as David said) add an explicit note in the madvise() manpage > about how that can interfere with software breakpoints and uprobes?
It does feel like it's the debuggers problem. The application doesn't know it's getting debugged. So the application does whatever it does. If GDB is debugging an application it should assume there's a problematic madvise() call which will hurt/stop the debugging from happening. It should endeavor to prevent that from happening. There are options in userspace to prevent it from happening. I'm sure madvise() is not the only thing GDB has to worry about w.r.t. screwing up the debugging. Noting it in the man page seems reasonable. Daniel
