>> Hi
>> We are working for running android in container, but we found that binder
>> is
>> not isolated by ipc namespace. Since binder is a form of IPC and therefore
>> should
>> be tied to ipc namespace. With this patch, we can run more than one android
>> container on one host.
>> This
We are working for running android in container, but we found that binder is
not isolated by ipc namespace. Since binder is a form of IPC and therefore
should
be tied to ipc namespace. With this patch, we can run more than one android
container on one host.
This patch move "binder_procs" and
> > > It's not obvious from this patch where this dependency comes
> > > from...why is SYSVIPC required? I'd like to not have to require
> > > IPC_NS either for devices.
> >
> > Yes, the patch is not highly dependent on SYSVIPC, but it will be
> > convenient if require it. I will update it to
> > > It's not obvious from this patch where this dependency comes
> > > from...why is SYSVIPC required? I'd like to not have to require
> > > IPC_NS either for devices.
> >
> > Yes, the patch is not highly dependent on SYSVIPC, but it will be
> > convenient if require it. I will update it to
Hi
We are working for running android in container, but we found that binder is
not isolated by ipc namespace. Since binder is a form of IPC and therefore
should
be tied to ipc namespace. With this patch, we can run more than one android
container on one host.
This patch move "binder_procs"
> -Original Message-
> From: Andrew Morton
> Sent: Wednesday, November 7, 2018 8:07 AM
> To: chouryzhou(周威)
> Cc: gre...@linuxfoundation.org; a...@android.com; tk...@android.com;
> d...@stgolabs.net; de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org
> S
> -Original Message-
> From: Andrew Morton
> Sent: Thursday, November 8, 2018 6:38 AM
> To: chouryzhou(周威)
> Cc: gre...@linuxfoundation.org; a...@android.com; tk...@android.com;
> d...@stgolabs.net; de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org
> Subject:
> From: Davidlohr Bueso
> Sent: Thursday, November 8, 2018 3:00 PM
>
> On Mon, 29 Oct 2018, chouryzhou(??) wrote:
> >@@ -63,6 +63,12 @@ struct ipc_namespace {
> >unsigned intmq_msg_default;
> >unsigned intmq_msgsize_default;
> >
> >+ /* next fields are for
We are working for running android in container, but we found that binder is
not isolated by ipc namespace. Since binder is a form of IPC and therefore
should
be tied to ipc namespace. With this patch, we can run more than one android
container on one host.
This patch move "binder_procs" and
> > > 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
>
> 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
> >
> > If IPC_NS is disabled, "current-nsporxy->ipc_ns" will also exists, it will
> > be a static
> > reference of "init_ipc_ns" (in ipc/msgutil.c, not defined in binder.c by
> > me) with
> > no namespace-ization. You will get the same one in all processes,
> > everything is
> > the same as
Currently android's binder is not isolated by ipc namespace. Since binder
is a form of IPC and therefore should be tied to ipc namespace. With this
patch, we can run multiple instances of android container on one host.
This patch move "binder_procs" and "binder_context" into ipc_namespace,
> I have not received an answer to my questions in the last version of this
> patch
> set. Also it would be good if I could be Cc'ed by default. I can't hunt down
> all
> patches.
> I do not know of any kernel entity, specifically devices, that change
> namespaces
> on open().
> This seems like
> On Fri, Nov 16, 2018 at 11:19:41AM -0800, Todd Kjos wrote:
> > On Thu, Nov 15, 2018 at 2:54 PM gre...@linuxfoundation.org
> > wrote:
> > ...
> > >
> > > A number of us have talked about this in the plumbers Android track, and
> > > a different proposal for how to solve this has been made that
> On Fri, Nov 16, 2018 at 11:19:41AM -0800, Todd Kjos wrote:
> > On Thu, Nov 15, 2018 at 2:54 PM gre...@linuxfoundation.org
> > wrote:
> > ...
> > >
> > > A number of us have talked about this in the plumbers Android track, and
> > > a different proposal for how to solve this has been made that
Currently android's binder is not isolated by ipc namespace. Since binder
is a form of IPC and therefore should be tied to ipc namespace. With this
patch, we can run multiple instances of android container on one host.
This patch move "binder_procs" and "binder_context" into ipc_namespace,
> I have not received an answer to my questions in the last version of this
> patch
> set. Also it would be good if I could be Cc'ed by default. I can't hunt down
> all
> patches.
> I do not know of any kernel entity, specifically devices, that change
> namespaces
> on open().
> This seems like
Hi
We are working for running android in container, but we found that binder is
not isolated by ipc namespace. Since binder is a form of IPC and therefore
should
be tied to ipc namespace. With this patch, we can run more than one android
container on one host.
This patch move "binder_procs"
>> Hi
>> We are working for running android in container, but we found that binder
>> is
>> not isolated by ipc namespace. Since binder is a form of IPC and therefore
>> should
>> be tied to ipc namespace. With this patch, we can run more than one android
>> container on one host.
>> This
We are working for running android in container, but we found that binder is
not isolated by ipc namespace. Since binder is a form of IPC and therefore
should
be tied to ipc namespace. With this patch, we can run more than one android
container on one host.
This patch move "binder_procs" and
> > > It's not obvious from this patch where this dependency comes
> > > from...why is SYSVIPC required? I'd like to not have to require
> > > IPC_NS either for devices.
> >
> > Yes, the patch is not highly dependent on SYSVIPC, but it will be
> > convenient if require it. I will update it to
> > > It's not obvious from this patch where this dependency comes
> > > from...why is SYSVIPC required? I'd like to not have to require
> > > IPC_NS either for devices.
> >
> > Yes, the patch is not highly dependent on SYSVIPC, but it will be
> > convenient if require it. I will update it to
> chouryzhou@, can you confirm that this implementation works for your
> android-in-container use-case?
>
> -Todd
>
We are running Android Pie in container now. If it works for later Android
release, it will works for us.
- choury
We are working for running android in container, but we found that binder is
not isolated by ipc namespace. Since binder is a form of IPC and therefore
should
be tied to ipc namespace. With this patch, we can run more than one android
container on one host.
This patch move "binder_procs" and
>
> 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
> >
> > If IPC_NS is disabled, "current-nsporxy->ipc_ns" will also exists, it will
> > be a static
> > reference of "init_ipc_ns" (in ipc/msgutil.c, not defined in binder.c by
> > me) with
> > no namespace-ization. You will get the same one in all processes,
> > everything is
> > the same as
> > > 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
> -Original Message-
> From: Andrew Morton
> Sent: Wednesday, November 7, 2018 8:07 AM
> To: chouryzhou(周威)
> Cc: gre...@linuxfoundation.org; a...@android.com; tk...@android.com;
> d...@stgolabs.net; de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org
> S
> -Original Message-
> From: Andrew Morton
> Sent: Thursday, November 8, 2018 6:38 AM
> To: chouryzhou(周威)
> Cc: gre...@linuxfoundation.org; a...@android.com; tk...@android.com;
> d...@stgolabs.net; de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org
> Subject:
> From: Davidlohr Bueso
> Sent: Thursday, November 8, 2018 3:00 PM
>
> On Mon, 29 Oct 2018, chouryzhou(??) wrote:
> >@@ -63,6 +63,12 @@ struct ipc_namespace {
> >unsigned intmq_msg_default;
> >unsigned intmq_msgsize_default;
> >
> >+ /* next fields are for
31 matches
Mail list logo
