>>> 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 tha
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 m
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(CLON
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 na
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
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_struc
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 re
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 tas
>>
>> (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 m
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
>
"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
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 exit_task_
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
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
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 t
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
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 con
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 o
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
>> sugges
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
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
[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 obser
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
[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
unconn
24 matches
Mail list logo
