Re: [PATCH] new interface: memory_object_get_proxy

[Joan Lledó]

Hi,

El 24/10/21 a les 19:50, Sergey Bugaev ha escrit:
> Naming: perhaps memory_object_create_vm_proxy ()? or even
> memory_object_create_task_vm_proxy ()?

I don't care about the name, you guys decide.

> I would expect the request port argument to be a vm_task_t (i.e. a
> vm_map), not a full task. But I see that you need to pass
> task->itk_space to memory_object_create_proxy (). But
> memory_object_create_proxy () doesn't actually need the task either,
> it just checks it against NULL (as usual) and never uses it again. So
> maybe it'd be cleaner to make both calls accept a vm_task_t? Not that
> this matters.

yes, that's true, but if we remove the parameter from 
memory_object_create_proxy() then we must remove it from all calls in 
the code, and in the documentation if there's any. So that's beyond the 
scope of this patch, it's something we can do later on.

> I don't think you can access the entry once you've unlocked the map.

You're probably right b/c it doesn't seem the entry is being accessed 
after the lock release in any other place of the code.

> Should the implementation cap the length to that of the entry
> silently, or should it return an error if called with an overly long
> len argument?

I don't know, Samuel, what do you think?

> I'm... not sure if this is wrong, but just to bring some attention to
> it: isn't memory_object_create_proxy () supposed to *consume* the
> 'objects' ports array in the successful case? I see it uses
> ipc_port_copy_send (object[0]), why does that not cause a leak? For a
> reference point, mach_ports_register (), which is another kernel RPC
> that accepts a port array, sure does consume it.
>
> If it *is* the case that memory_object_create_proxy () should consume
> the ports, then your new routine should make an extra ref to the pager
> port before passing it to memory_object_create_proxy ().

I'm not familiar with the concept of consuming objects, could you 
explain it to me?