Open dmik opened 4 years ago
Also, before we decide how to proceed, we should find more real-life use cases for partial mprotect
for better understanding of requirements. The case of #74 is not very representative since mprotect
is only needed there in order to trigger failures of some memchr
tests. Not real life usage, actually.
Note also that there is madvice
which in our case also allows for committing and decommitting the pages but, as opposed to mprotect
it doesn't change page access mode as it's seen by our mmap implementation and therefore even partial madvice
is supported.
Currently, our
mprotect
is quite limited. It returns EACCES for non-anonymous file mappings and, as of #74, it also returns EACCES when applied in part to an anonymous mapping. Both limitations have the same root: we already use page protection flags for our own management so messing with them beyond it will break it.For example, the page committed bit is used in all mappings to implement lazy page memory allocation on first access. The page write bit is used as a trigger to catch writes to non-anonymous mappings in order to write dirty pages to the underlying files.
As for anonymous mappings, we used to support partial
mprotect
on them but it showed bugs as #74 demonstrates so it had to be disabled. In short, the reason is that our internal mmap representation only keeps track ofmmap
-level protection flags for the whole region, not for individual pages. We could add a map of per-page protection flags but this needs some redesign of internal structures and it's better to be done globally, taking other needs into account (like supporting mprotect for non-anonymous mappings). This is what this ticket is about.