On 4/30/26 11:16, Oleg Nesterov wrote:
> On 04/29, Daniel Walker (danielwa) 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?
>
> Not sure... uprobes assumes that it owns the modified page and nobody
> can modify/unmap it, including the probed application or debugger.
>
> But may be MADV_DONTNEED should not set zap_details.even_cows == true
> by default ?
It should. If you do mmap(MAP_PRIVATE, fd), and modify some pages, MADV_DONTNEED
must zap these pages.
There is a recurring confusion about MADV_DONTNEED.
The man page is relatively clear about the semantics ("subsequent accesses of
pages in the range will succeed, but will result in either repopulating the
memory ... or zero-fill-on-demand pages for anonymous private mappings").
But the initial sentence "Do not expect access in the near future. (For the
time being, the application is finished with the given range, so the kernel can
free resources associated with it.)" mostly only makes sense for shared
mappings.
Maybe we could emphasize that MADV_DONTNEED is not a hint but something
destructive in private mappings.
And that MADV_DONTNEED is not for memory reclaim, just like munmap() is not for
memory reclaim.
--
Cheers,
David
