On Thu, Dec 14, 2023 at 6:07 PM Stephen Röttger sroettger@google.com wrote:
On Thu, Dec 14, 2023 at 2:31 AM Linus Torvalds torvalds@linux-foundation.org wrote:
On Wed, 13 Dec 2023 at 16:36, Jeff Xu jeffxu@google.com wrote:
IOW, when would you *ever* say "seal this area, but MADV_DONTNEED is ok"?
The MADV_DONTNEED is OK for file-backed mapping.
Right. It makes no semantic difference. So there's no point to it.
My point was that you added this magic flag for "not ok for RO anon mapping".
It's such a *completely* random flag, that I go "that's just crazy random - make sealing _always_ disallow that case".
So what I object to in this series is basically random small details that should just eb part of the basic act of sealing.
I think sealing should just mean "you can't do any operations that have semantic meaning for the mapping, because it is SEALED".
So I think sealing should automatically mean "can't do MADV_DONTNEED on anon memory", because that's basically equivalent to a munmap/remap operation.
In Chrome, we have a use case to allow MADV_DONTNEED on sealed memory.
I don't want to be that guy (*believe me*), but what if there was a way to attach BPF programs to mm's? Such that you could handle 'seal failures' in BPF, and thus allow for this sort of weird semantics? e.g: madvise(MADV_DONTNEED) on a sealed region fails, kernel invokes the BPF program (that chrome loaded), BPF program sees it was a MADV_DONTNEED and allows it to proceed.
It requires BPF but sounds like a good compromise in order to not get an ugly API?