the lifetime of ipc_namespace
Modeled after generic net-ns pointers (commit dec827d), but simplified
to accommodate a single user for now (reduce code churn):
5. only one caller can register at a time
6. caller must register at boot time (not to be used by modules)
Signed-off-by: Oren Laadan
Signed-off
remain global, except for the list of processes
that hold an open binder device (reported per namespace).
Signed-off-by: Oren Laadan
Acked-by: Amir Goldstein
---
drivers/staging/android/Kconfig | 1 +
drivers/staging/android/binder.c | 172 ---
2 files changed
binder handles provided by the context manager.
Thanks,
Oren.
Oren Laadan (2):
ipc namespace: a generic per-ipc pointer and peripc_ops
binder: implement namepsace support for Android binder driver
drivers/staging/android/Kconfig | 1 +
drivers/staging/android/binder.c | 172
remain global, except for the list of processes
that hold an open binder device (reported per namespace).
Signed-off-by: Oren Laadan or...@cellrox.com
Acked-by: Amir Goldstein a...@cellrox.com
---
drivers/staging/android/Kconfig | 1 +
drivers/staging/android/binder.c | 172
binder handles provided by the context manager.
Thanks,
Oren.
Oren Laadan (2):
ipc namespace: a generic per-ipc pointer and peripc_ops
binder: implement namepsace support for Android binder driver
drivers/staging/android/Kconfig | 1 +
drivers/staging/android/binder.c | 172
the lifetime of ipc_namespace
Modeled after generic net-ns pointers (commit dec827d), but simplified
to accommodate a single user for now (reduce code churn):
5. only one caller can register at a time
6. caller must register at boot time (not to be used by modules)
Signed-off-by: Oren Laadan
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious.
It isn't strictly necessary to export a new interface in order to
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious.
It isn't strictly necessary to export a new interface in order to
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I strongly second Kirill on this matter.
IMHO, we should _avoid_ as much as possible exposing internal kernel
state to applications, unless a _real_ need for it is _clearly_
demonstrated. The reasons for this are quite obvious
Pavel Emelyanov wrote:
> Oren Laadan wrote:
>> Serge E. Hallyn wrote:
>>> Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
>>>> Oren Laadan wrote:
>>>>> Serge E. Hallyn wrote:
>>>>>> Quoting Oren Laadan ([EMAIL PROTECTED]):
>>>
Pavel Emelyanov wrote:
Oren Laadan wrote:
Serge E. Hallyn wrote:
Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
Oren Laadan wrote:
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I hate to bring this again, but what if the admin in the container
mounts an external file
Serge E. Hallyn wrote:
> Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
>> Oren Laadan wrote:
>>> Serge E. Hallyn wrote:
>>>> Quoting Oren Laadan ([EMAIL PROTECTED]):
>>>>> I hate to bring this again, but what if the admin in the container
>>>
Serge E. Hallyn wrote:
Quoting Pavel Emelyanov ([EMAIL PROTECTED]):
Oren Laadan wrote:
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I hate to bring this again, but what if the admin in the container
mounts an external file system (eg. nfs, usb, loop mount from a file
Serge E. Hallyn wrote:
> Quoting Oren Laadan ([EMAIL PROTECTED]):
>> I hate to bring this again, but what if the admin in the container
>> mounts an external file system (eg. nfs, usb, loop mount from a file,
>> or via fuse), and that file system already has a device that we
I hate to bring this again, but what if the admin in the container
mounts an external file system (eg. nfs, usb, loop mount from a file,
or via fuse), and that file system already has a device that we would
like to ban inside that container ?
Since anyway we will have to keep a white- (or
I hate to bring this again, but what if the admin in the container
mounts an external file system (eg. nfs, usb, loop mount from a file,
or via fuse), and that file system already has a device that we would
like to ban inside that container ?
Since anyway we will have to keep a white- (or
Serge E. Hallyn wrote:
Quoting Oren Laadan ([EMAIL PROTECTED]):
I hate to bring this again, but what if the admin in the container
mounts an external file system (eg. nfs, usb, loop mount from a file,
or via fuse), and that file system already has a device that we would
like to ban inside
Cedric Le Goater wrote:
>>> Index: 2.6.24-rc3-mm2/include/linux/sched.h
>>> ===
>>> --- 2.6.24-rc3-mm2.orig/include/linux/sched.h
>>> +++ 2.6.24-rc3-mm2/include/linux/sched.h
>>> @@ -27,6 +27,7 @@
>>> #define CLONE_NEWUSER
Cedric Le Goater wrote:
Index: 2.6.24-rc3-mm2/include/linux/sched.h
===
--- 2.6.24-rc3-mm2.orig/include/linux/sched.h
+++ 2.6.24-rc3-mm2/include/linux/sched.h
@@ -27,6 +27,7 @@
#define CLONE_NEWUSER 0x1000
20 matches
Mail list logo
