Re: [PATCH] mm/madvise: preserve uprobe breakpoints across MADV_DONTNEED

["David Hildenbrand (Arm)" <david@kernel.org>]

On 4/30/26 21:25, Daniel Walker (danielwa) wrote:
> 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)
>> <danielwa@cisco.com> wrote:
>>>
>>>
>>> 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,

Private mapping, yes. MADV_DONTNEED indeed interacts poorly here.

uprobe registration indeed fails if VM_WRITE is set (valid_vma), but nothing
stops the VMA from getting mprotect'ed later I guess, to allow for write access.

We could try marking a VMA that has uprobes, to then pr_warn_once() of
MADV_DONTNEED is done on such a VMA. It wouldn't sort out ptrace access.

>> and/or (as David said) add an explicit note in the madvise() manpage
>> about how that can interfere with software breakpoints and uprobes?

I guess not just software breakpoints, but any modifications done by a debugger.

I guess for read+execute file mapping we would expect these to be software
breakpoints.

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

I assume the bigger problem here is that MADV_DONTNEED was used for memory
reclaim, when in fact, it shouldn't be used for that.

For shared mappings, the man page even documents: "MADV_DONTNEED might not lead
to immediate freeing of the pages in the range.  The kernel is free to delay
freeing the pages until an appropriate moment.".

MADV_PAGEOUT is better for reclaim, but it has its limitations when it comes to
pages shared with other processes.

-- 
Cheers,

David