Re: About namespaces and unshare() syscall.

Re: About namespaces and unshare() syscall.

[Eric W. Biederman]

Raphael S Carvalho <raphael.scarv@gmail.com> writes:

> Hi Eric W. Biederman and Serge Hallyn,
>
> I'm a newcomer to Linux kernel Development, and I really like the way
> Linux manages namespaces.
> By the way, I'm studying how copy_process() deals with it. I mean,
> sharing namespaces by default and
> duplicating namespaces on demand. 
> I would appreciate if you can give me tips about where to get started
> (Which areas are needing either help or improvement). 

Public mailing lists are usually good forums for discussion.

> Regarding to unshare syscall, I really care about how the following
> fragment of code will work in the future:
> (kernel/fork.c) static int check_unshare_flags(unsigned long
> unshare_flags):
> ...
> 1735        if (unshare_flags & (CLONE_THREAD | CLONE_SIGHAND |
> CLONE_VM)) {
> 1736                /* FIXME: get_task_mm() increments ->mm_users */
> 1737                if (atomic_read(&current->mm->mm_users) > 1)
> 1738                        return -EINVAL;
> 1739        }
>
> For example, suppose CLONE_VM was added to Unshare syscall, and so you
> created an application which relies on this new feature (Unshare VM).
> So I found your application in the Internet, but I'm running a kernel
> which still has the above checking.
>
> It won't work properly! why?
> Taking a careful look at it, I realized that if one of those flags
> were passed to the unshare syscall and the current process is sharing
> its VM among other processes, the syscall would always return an
> invalid error.
>

Which is exactly correct behavior for threaded applications.
Essentially unshare(CLONE_VM) means make me not a thread.  If
current->mm->mm_users == 1 there is nothing to do.  Otherwise something
has to happen.  And if there is no CLONE_VM support in the kernel 
nothing can happen.

> Conclusion: Your application (relying on Unshare CLONE_VM feature)
> wouldn't work on previous kernel versions since the old
> check_unshare_flags() was programmed so that CLONE_VM (with current
> process sharing its VM) is implicitly an invalid operation. Thus,
> lacking backward compatibility.

Wrong.  You get a nice error telling you that CLONE_VM doesn't work for
threaded applications on the kernel that you are running.

> I also was reading why CLONE_VM was removed from Unshare syscall, it
> seems a core dump could be processing at the same time, so bad things
> might happen. However, it seems this feature will only be implemented
> when really needed.

Which is like most of the kernel.  If someone cares enough to implement
things properly something is implemented.  If no one cares enough the
feature is never implemented, never merged, or never used and removed
when someone notice no one really cares.

Eric

About namespaces and unshare() syscall.

[Raphael S Carvalho]

Hi Eric W. Biederman and Serge Hallyn,

I'm a newcomer to Linux kernel Development, and I really like the way
Linux manages namespaces.
By the way, I'm studying how copy_process() deals with it. I mean,
sharing namespaces by default and duplicating namespaces on demand.
I would appreciate if you can give me tips about where to get started
(Which areas are needing either help or improvement).

Regarding to unshare syscall, I really care about how the following
fragment of code will work in the future:
(kernel/fork.c) static int check_unshare_flags(unsigned long unshare_flags):
...
1735        if (unshare_flags & (CLONE_THREAD | CLONE_SIGHAND | CLONE_VM)) {
1736                /* FIXME: get_task_mm() increments ->mm_users */
1737                if (atomic_read(&current->mm->mm_users) > 1)
1738                        return -EINVAL;
1739        }

For example, suppose CLONE_VM was added to Unshare syscall, and so you
created an application which relies on this new feature (Unshare VM).
So I found your application in the Internet, but I'm running a kernel
which still has the above checking.

It won't work properly! why?
Taking a careful look at it, I realized that if one of those flags
were passed to the unshare syscall and the current process is sharing
its VM among other processes, the syscall would always return an
invalid error.

Conclusion: Your application (relying on Unshare CLONE_VM feature)
wouldn't work on previous kernel versions since the old
check_unshare_flags() was programmed so that CLONE_VM (with current
process sharing its VM) is implicitly an invalid operation. Thus,
lacking backward compatibility.

I also was reading why CLONE_VM was removed from Unshare syscall, it
seems a core dump could be processing at the same time, so bad things
might happen. However, it seems this feature will only be implemented
when really needed.

Regards,
Raphael S.Carvalho <raphael.scarv@gmail.com>