On Mon, Aug 16, 2021 at 10:28 PM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > Sergey Bugaev, le lun. 16 août 2021 21:59:47 +0300, a ecrit: > > IMO the proper way to get mremap () is vm_remap () > > But that doesn't answer Joan's need for getting a memory object, to be > able to put a proxy memory object on top of it to make it read-only.
Ah, I wasn't really following the discussion. I'm talking specifically about mremap. > But then it'll create a pile of proxies if the application calls mremap > several times, which I guess some applications will happily try to do. No, for two reasons: 1. The kernel should just transparently short-circuit nested proxies at proxy creation time — make the new proxy reference the original memory object and not the other proxy; this way the other proxy can be deallocated when it's no longer referenced, even if the new proxy continues to exist. I believe this is what Joan has suggested above: > I think it'd be a better solution to move the call to > memory_object_proxy_valid() and the start value overwrite to > memory_object_create_proxy() 2. As always, when you map a proxy it's the original memory object that actually gets mapped (and referenced, and kept alive); the proxy will then get deallocated when the task does mach_port_deallocate (mach_task_self (), proxy). In other words, the proxy is short-lived and only serves to make this whole operation representable. (This is transparent to userspace though: from its perspective it's the proxy that stays mapped.) Sergey
