Re: Re: [PATCH V3] binder: ipc namespace support for android binder

[chouryzhou(åå)]

>Â
> I still don't understand the dependencies on SYSVIPC or POSIX_MQUEUE.
> It seems like this mechanism would work even if both are disabled --
> as long as IPC_NS is enabled. Seems cleaner to change init/Kconfig and
> allow IPC_NS if CONFIG_ANDROID_BINDER_IPC and change this line to
> "#ifndef CONFIG_IPC_NS"

Let me explain it in detail. If SYSIPC and IPC_NS are both defined, Â
current->nsproxy->ipc_ns will save the ipc namespace variables. We just useÂ
it. If SYSIPC (or POSIX_MQUEUE) is defined while IPC_NS is not set,Â
current->nsproxy->ipc_ns will always refer to init_ipc_ns in ipc/msgutil.c,Â
which is also fine to us. But if neither SYSIPC nor POSIX_MQUEUE is setÂ
(IPC_NS can't be set in this situation), there is no current->nsproxy->ipc_ns.
We make a fack init_ipc_ns here and use it.

> why eliminate name? The string name is very useful for differentiating
> normal "framework" binder transactions vs "hal" or "vendor"
> transactions. If we just have a device number it will be hard to tell
> in the logs even which namespace it belongs to. We need to keep both
> the "name" (for which there might be multiple in each ns) and some
> indication of which namespace this is. Maybe we assign some sort of
> namespace ID during binder_init_ns().

ÂI will remain the name of device. The Âinum of ipc_ns can be treated asÂ
namespace ID in ipc_ns.

> As mentioned above, we need to retain name and probably also want a ns
> id of some sort. So context now has 3 components if IPC_NS, so maybe a
> helper function to print context like:
>Â
> static void binder_seq_print_context(struct seq_file *m, struct
> binder_context *context)
> {
> #ifdef CONFIG_IPC_NS
> Â Â Â Â Â seq_printf(m, "%d-%d-%s", context->ns_id, context->device,
> context->name);
> #else
> Â Â Â Â Â seq_printf(m, "%d", context->name);
> #endif
> }
>Â
> (same comment below everywhere context is printed)
>Â
> Should these debugfs nodes should be ns aware and only print debugging
> info for the context of the thread accessing the node? If so, we would
> also want to be namespace-aware when printing pids.

Nowadays, debugfs is not namespace-ized, and pid namespace is not associatedÂ
with ipc namespace. ÂWill it be more complicated to debug this if we just printÂ
the info for current thread? Because we will have to enter the ipc namespaceÂ
firstly. But add ipc inum should be no problem.

- choury -