(3) move mq_ns out of nsproxy. where shall I put it then ?
(3.1) task_struct ?
(3.2) mnt namespace maybe ?
I think the last one is the way to go.
mnt_namespace points to mq_ns.
At clone(CLONE_NEWMNT), the new mnt namespace receives a copy of the
parent's mq_ns.
hmm, hmm,
Eric W. Biederman wrote:
Serge E. Hallyn [EMAIL PROTECTED] writes:
(3.2) mnt namespace maybe ?
I think the last one is the way to go.
mnt_namespace points to mq_ns.
At clone(CLONE_NEWMNT), the new mnt namespace receives a copy of the
parent's mq_ns.
If a task does
mount -o
Serge E. Hallyn wrote:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
(3.2) mnt namespace maybe ?
I think the last one is the way to go.
mnt_namespace points to mq_ns.
At clone(CLONE_NEWMNT), the new mnt namespace receives a copy of the
Eric W. Biederman wrote:
Cedric Le Goater [EMAIL PROTECTED] writes:
Hello Eric,
I've spent some time on the code and I'm facing some issues with the nsproxy
API if we are to keep the mqueue namespace in nsproxy:
int copy_namespaces(unsigned long flags, struct task_struct *tsk);
Cedric Le Goater [EMAIL PROTECTED] writes:
ok. complete isolation would require 2 steps. I guess this is
acceptable because mq uses a fs
allowing the host to see the child's /dev/mqueue is also 'a nice
to have' feature. unfortunately, we can't do that for all namespaces,
for sysvipc for
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
Eric W. Biederman wrote:
Serge E. Hallyn [EMAIL PROTECTED] writes:
(3.2) mnt namespace maybe ?
I think the last one is the way to go.
mnt_namespace points to mq_ns.
At clone(CLONE_NEWMNT), the new mnt namespace receives a copy of
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
(3) move mq_ns out of nsproxy. where shall I put it then ?
(3.1) task_struct ?
(3.2) mnt namespace maybe ?
I think the last one is the way to go.
mnt_namespace points to mq_ns.
At clone(CLONE_NEWMNT), the new mnt
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
(3.2) mnt namespace maybe ?
I think the last one is the way to go.
mnt_namespace points to mq_ns.
At
When a task does mq_open(name, flag), then name is in the mqueuefs
found in current-nsproxy-mnt_namespace-mqns.
But if a task does
clone(CLONE_NEWMNT);
mount --move /dev/mqueue /oldmqueue
mount -o newinstance -t mqueue none /dev/mqueue
then that task can find files for the
Cedric Le Goater [EMAIL PROTECTED] writes:
Hello Eric,
I've spent some time on the code and I'm facing some issues with the nsproxy
API if we are to keep the mqueue namespace in nsproxy:
int copy_namespaces(unsigned long flags, struct task_struct *tsk);
void
Serge E. Hallyn [EMAIL PROTECTED] writes:
(3.2) mnt namespace maybe ?
I think the last one is the way to go.
mnt_namespace points to mq_ns.
At clone(CLONE_NEWMNT), the new mnt namespace receives a copy of the
parent's mq_ns.
If a task does
mount -o newinstance -t mqueue none
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
(3.2) mnt namespace maybe ?
I think the last one is the way to go.
mnt_namespace points to mq_ns.
At clone(CLONE_NEWMNT), the new mnt namespace receives a copy of the
parent's mq_ns.
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
Cedric Le Goater wrote:
Eric W. Biederman wrote:
Cedric Le Goater [EMAIL PROTECTED] writes:
H. Peter Anvin wrote:
Cedric Le Goater wrote:
I suggest newinstance, but newns works, too.
Could we also use this mount option to 'unshare' a new
Cedric Le Goater wrote:
Eric W. Biederman wrote:
Cedric Le Goater [EMAIL PROTECTED] writes:
H. Peter Anvin wrote:
Cedric Le Goater wrote:
I suggest newinstance, but newns works, too.
Could we also use this mount option to 'unshare' a new posix message
queue namespace ?
Sorry, I fail to
H. Peter Anvin wrote:
[EMAIL PROTECTED] wrote:
I don't like the name newmnt for the option; it is not just another
mount, but a whole new instance of the pty space.
I agree. Its mostly a place-holder for now. How about newns or newptsns ?
I suggest newinstance, but newns works, too.
Cedric Le Goater wrote:
I suggest newinstance, but newns works, too.
Could we also use this mount option to 'unshare' a new posix message queue
namespace ?
Sorry, I fail to see the connection with devpts here? Are you
suggesting using the same option for another filesystem (if so,
Cedric Le Goater wrote:
H. Peter Anvin wrote:
Cedric Le Goater wrote:
I suggest newinstance, but newns works, too.
Could we also use this mount option to 'unshare' a new posix message
queue namespace ?
Sorry, I fail to see the connection with devpts here? Are you
suggesting using the same
H. Peter Anvin wrote:
Cedric Le Goater wrote:
I suggest newinstance, but newns works, too.
Could we also use this mount option to 'unshare' a new posix message
queue namespace ?
Sorry, I fail to see the connection with devpts here? Are you
suggesting using the same option for another
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
H. Peter Anvin wrote:
Cedric Le Goater wrote:
I suggest newinstance, but newns works, too.
Could we also use this mount option to 'unshare' a new posix message
queue namespace ?
Sorry, I fail to see the connection with devpts here?
Cedric Le Goater [EMAIL PROTECTED] writes:
H. Peter Anvin wrote:
Cedric Le Goater wrote:
I suggest newinstance, but newns works, too.
Could we also use this mount option to 'unshare' a new posix message
queue namespace ?
Sorry, I fail to see the connection with devpts here? Are you
Eric W. Biederman wrote:
Cedric Le Goater [EMAIL PROTECTED] writes:
H. Peter Anvin wrote:
Cedric Le Goater wrote:
I suggest newinstance, but newns works, too.
Could we also use this mount option to 'unshare' a new posix message
queue namespace ?
Sorry, I fail to see the connection with
[EMAIL PROTECTED] wrote:
TODO:
- Remove even initial kernel mount of devpts ? (If we do, how
do we preserve single-mount semantics) ?
Doesn't make sense unless we decide to drop single-mount semantics in
the (far) future. As long as we have an instance that services
H. Peter Anvin [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
TODO:
- Remove even initial kernel mount of devpts ? (If we do, how
do we preserve single-mount semantics) ?
Doesn't make sense unless we decide to drop single-mount semantics in the
(far) future. As long as we
[EMAIL PROTECTED] wrote:
I don't like the name newmnt for the option; it is not just another
mount, but a whole new instance of the pty space.
I agree. Its mostly a place-holder for now. How about newns or newptsns ?
I suggest newinstance, but newns works, too.
I observe you didn't
24 matches
Mail list logo
