Question: copy_process() and CLONE_NEWNS

Question: copy_process() and CLONE_NEWNS

[Kevin Wilson]

Hi all,
question:

In copy_process() we have:

static struct task_struct *copy_process(unsigned long clone_flags,
                                         unsigned long stack_start,
                                         struct pt_regs *regs,
                                         unsigned long stack_size,
                                         int __user *child_tidptr,
                                         struct pid *pid,
                                         int trace)
 {
         int retval;
         struct task_struct *p;
         int cgroup_callbacks_done = 0;

         if ((clone_flags & (CLONE_NEWNS|CLONE_FS)) == (CLONE_NEWNS|CLONE_FS))
                 return ERR_PTR(-EINVAL);
 ...
...


see :http://lxr.free-electrons.com/source/kernel/fork.c#L1128

Why is the CLONE_NEWNS, when set, cause an error in copy_process(), as
shown above ?
is it not permitted that CLONE_NEWNS will be set ?

rgs,
Kevin

Question: copy_process() and CLONE_NEWNS

[Tobias Boege]

On Fri, 01 Feb 2013, Kevin Wilson wrote:
> Hi all,
> question:
> 
> In copy_process() we have:
> 
> static struct task_struct *copy_process(unsigned long clone_flags,
>                                          unsigned long stack_start,
>                                          struct pt_regs *regs,
>                                          unsigned long stack_size,
>                                          int __user *child_tidptr,
>                                          struct pid *pid,
>                                          int trace)
>  {
>          int retval;
>          struct task_struct *p;
>          int cgroup_callbacks_done = 0;
> 
>          if ((clone_flags & (CLONE_NEWNS|CLONE_FS)) == (CLONE_NEWNS|CLONE_FS))
>                  return ERR_PTR(-EINVAL);
>  ...
> ...
> 
> 
> see :http://lxr.free-electrons.com/source/kernel/fork.c#L1128
> 
> Why is the CLONE_NEWNS, when set, cause an error in copy_process(), as
> shown above ?
> is it not permitted that CLONE_NEWNS will be set ?

It seems so :-)

clone(2)'s manpage also says:

"It is not permitted to specify both CLONE_NEWNS and CLONE_FS in the same
clone() call."

Regards,
Tobi

Question: copy_process() and CLONE_NEWNS

[Denis Kirjanov]

On 2/1/13, Kevin Wilson <wkevils@gmail.com> wrote:
> Hi all,
> question:
>
> In copy_process() we have:
>
> static struct task_struct *copy_process(unsigned long clone_flags,
>                                          unsigned long stack_start,
>                                          struct pt_regs *regs,
>                                          unsigned long stack_size,
>                                          int __user *child_tidptr,
>                                          struct pid *pid,
>                                          int trace)
>  {
>          int retval;
>          struct task_struct *p;
>          int cgroup_callbacks_done = 0;
>
>          if ((clone_flags & (CLONE_NEWNS|CLONE_FS)) ==
> (CLONE_NEWNS|CLONE_FS))
>                  return ERR_PTR(-EINVAL);
>  ...
> ...
>

man unshare



> see :http://lxr.free-electrons.com/source/kernel/fork.c#L1128
>
> Why is the CLONE_NEWNS, when set, cause an error in copy_process(), as
> shown above ?
> is it not permitted that CLONE_NEWNS will be set ?
>
> rgs,
> Kevin
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>


-- 
Regards,
Denis

Question: copy_process() and CLONE_NEWNS

[Valdis.Kletnieks at vt.edu]

On Fri, 01 Feb 2013 12:58:01 +0100, Tobias Boege said:

> clone(2)'s manpage also says:
>
> "It is not permitted to specify both CLONE_NEWNS and CLONE_FS in the same
> clone() call."

Mostly because nobody's ever figured out what the actual semantics of
having both of them set would be. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130204/75a40a7e/attachment.bin