[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] new interface: memory_object_get_proxy

From: Joan Lledó
Subject: Re: [PATCH] new interface: memory_object_get_proxy
Date: Sat, 30 Oct 2021 08:38:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0


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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]