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.
I also think that sealing should just automatically mean "can't do mprotect any more".
And yes, the OpenBSD semantics of "immutable" apparently allowed reducing permissions, but even the openbsd man-page seems to think that was a bug, so we should just not allow it. And the openbsd case seems to be because of how they made certain things immutable by default, which is different from what this mseal() thing is.
End result: I'd really like to make the thing conceptually simpler, rather than add all those random (*very* random in case of MADV_DONTNEED) special cases.
Is there any actual practical example of why you'd want a half-sealed thing?
And no, I didn't read the pdf that was attached. If it can't just be explained in plain language, it's not an explanation.
I'd love for "sealed" to be just a single bit in the vm_flags things that we already have. Not a config option. Not some complicated thing that is hard to explain. A simple "I have set up this mapping, you can't change it any more".
And if it cannot be that kind of thing, I want to have clear and obvious examples of why it can't be that simple thing.
Not a pdf file that describes some google-chrome design. Something down-to-earth and practical (and not a "we might want this in the future" thing either).
IOW, what is wrong with "THIS VMA SETUP CANNOT BE CHANGED ANY MORE"?
Nothing less, but also nothing more. No random odd bits that need explaining.
Linus