Re: PCI arbiter memory mapping

[Sergey Bugaev]

On Mon, Aug 16, 2021 at 10:28 PM Samuel Thibault
<samuel.thibault@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