On 4/29/26 15:15, Darko Tominac wrote: > When uprobes are active, MADV_DONTNEED can discard file-backed pages > that contain uprobe software breakpoint instructions. Because the
If my memory serves me right, uprobes can only be installed in MAP_PRIVATE fil mappings. Installing a uprobe breaks CoW by installing an anonymous page. Not a file-backed page. > 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. :) > > Note that MADV_FREE is not affected: it only operates on anonymous VMAs > (madvise_free_single_vma() rejects non-anonymous VMAs with -EINVAL), > while uprobes only instrument file-backed mappings, so the two can never > overlap. > > A concrete example is a userspace memory reclamation subsystem that > periodically calls madvise(MADV_DONTNEED) on file-backed text pages to > release memory. It shouldn't do that on a MAP_PRIVATE file-backed VMA. It breaks the programn, including uprobes and anything else that breaks CoW in there. If it's using MADV_DONTNEED, it is damaging the application. MADV_DONTNEED is not for memory reclaim. -- Cheers, David
