Re: [PATCH v3 2/5] mm/mseal: update madvise() logic

[David Hildenbrand]

On 24.07.25 20:56, David Hildenbrand wrote:
> > To summarize all the discussion points so far:
> > 1. It's questionable behavior for madvise to allow destructive
> > behavior for read-only anonymous mappings, regardless of mseal state.
>   > 2. We could potentially fix point 1 within madvise itself, without>
> involving mseal, as Linus desires.
>
> IIUC: disallow madvise(MADV_DONTNEED) without PROT_WRITE.
>
> I am 99.99999% sure that that would break user case, unfortunately.
>
> > 3. Android userspace uses destructive madvise to free up RAM, but I
> > need to take a closer look at the patterns and usage to understand why
> > they do that.
>
> I am shocked that you question why they would use MADV_DONTNEED instead
> of ...
>
>   > 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.
>
> ... MADV_COLD / MADV_PAGEOUT.
>
> I am also shocked that you think asking apps to switch would not make us
> break user space.
> >> 5. We could investigate more based on vma->anon_vma
> Or we do what sealing is supposed to do.

Sorry for the rather hard replies, I was not understanding at all what 
you were getting at really.

> With the hope that this sealing fix here would not break user space.

Is your concern that something (in Chrome?) would be relying on 
MADV_DONTNEED working in case we had a MAP_PRIVATE R/O file mapping?

Again, disallowing that completely (even without mseal()) would break 
user space, I am very sure.

Whether we should allow zapping *anonymous folios* in MAP_PRIVATE R/O 
file mapping is a good  question, hard to tell if that would break anything.

For zapping *anonymous folios* in MAP_PRIVATE R/O anon mappings, I am 
sure there are use cases around userfaultfd, I'm afraid ...

--
Cheers,

David / dhildenb