On Thu, Jul 24, 2025 at 11:53:52PM +0200, David Hildenbrand wrote: > > > > > 4. We could ask applications to switch to non-destructive madvise, > > > like MADV_COLD or MADV_PAGEOUT. Or, another option is that we could > > > switch the kernel to use non-destructive madvise implicitly for > > > destructive madvise in suitable situations. > > > > Umm what? I don't understand your point. > > > > > 5. We could investigate more based on vma->anon_vma > > > > I have no idea what you mean by this. I am an rmap maintainer and have > > worked extensively with anon_vma, what's the point exactly? > > I think, the idea would be to add an additional anon_vma check: so if you > have a MAP_PRIVATE file mapping, you could still allow for MADV_DONTNEED if > you are sure that there are no anon folios in there.
OK this is a more coherent explanation of what this means, thanks. In no other case are we checking if there is data there that is different from post-discard, so this would be inconsistent with other disallowed madvise() modes. Equally, to me setting mprotect(PROT_READ) then mseal()'ing is a contract, and adding a 'but we let you discard if we go check and it's fine' feels like really inconsistent semantics. We're dealing with a real edge-case scenario here of a MAP_PRIVATE mapping (which means you are essentially asking for anon) being intentionally marked read-only then sealed. I think it's _better_ to be clearer on this. > > If there is an anon_vma, the only way to find out is actually looking at the > page tables. > > To be completely precise, one would have to enlighten the zap logic to > refuse to zap if there is any anon folio there, and bail out. Yeah absolutely not this would be crazy, especially for such an edge case. I'm sure you agree :) > > -- > Cheers, > > David / dhildenb >
