[PATCH 1/2] unshare.2: Document CLONE_NEWNET

[PATCH 1/2] unshare.2: Document CLONE_NEWNET

[Lucian Adrian Grijincu]

Signed-off-by: Lucian Adrian Grijincu <lucian.grijincu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 man2/unshare.2 |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/man2/unshare.2 b/man2/unshare.2
index 051ebf5..2e43806 100644
--- a/man2/unshare.2
+++ b/man2/unshare.2
@@ -93,6 +93,10 @@ its namespace which is not shared with any other process.
 Specifying this flag automatically implies
 .B CLONE_FS
 as well.
+.TP
+.B CLONE_NEWNET " (since Linux 2.6.24)"
+Unshare the old network namespace. Specifying this flag
+will move the process into a new network namespace.
 .\" As at 2.6.16, the following forced implications also apply,
 .\" although the relevant flags are not yet implemented.
 .\" If CLONE_THREAD is set force CLONE_VM.
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] clone.2: remove forward reference to 2.6.28

[Lucian Adrian Grijincu]

Signed-off-by: Lucian Adrian Grijincu <lucian.grijincu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 man2/clone.2 |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/man2/clone.2 b/man2/clone.2
index a126a05..17572d2 100644
--- a/man2/clone.2
+++ b/man2/clone.2
@@ -288,8 +288,6 @@ This flag can't be specified in conjunction with
 .BR CLONE_SYSVSEM .
 .TP
 .BR CLONE_NEWNET " (since Linux 2.6.24)"
-(The implementation of this flag is not yet complete,
-but probably will be mostly complete by about Linux 2.6.28.)
 
 If
 .B CLONE_NEWNET
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] clone.2: remove forward reference to 2.6.28

[Michael Kerrisk]

Hi Lucian,

On Fri, Oct 15, 2010 at 3:25 AM, Lucian Adrian Grijincu
<lucian.grijincu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Signed-off-by: Lucian Adrian Grijincu <lucian.grijincu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  man2/clone.2 |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/man2/clone.2 b/man2/clone.2
> index a126a05..17572d2 100644
> --- a/man2/clone.2
> +++ b/man2/clone.2
> @@ -288,8 +288,6 @@ This flag can't be specified in conjunction with
>  .BR CLONE_SYSVSEM .
>  .TP
>  .BR CLONE_NEWNET " (since Linux 2.6.24)"
> -(The implementation of this flag is not yet complete,
> -but probably will be mostly complete by about Linux 2.6.28.)

I am reluctant to apply this patch, since it would be more useful to
document exactly when the implementation was completed. Would you be
able to determine this information and resubmit the patch?

Thanks,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] clone.2: remove forward reference to 2.6.28

[Lucian Adrian Grijincu]

On Sun, Oct 24, 2010 at 5:42 PM, Michael Kerrisk <mtk.manpages-Re5JQEeQqe8@public.gmane.orgm> wrote:
> I am reluctant to apply this patch, since it would be more useful to
> document exactly when the implementation was completed. Would you be
> able to determine this information and resubmit the patch?

In http://lxc.sourceforge.net/man/lxc.html they say: "With the kernel
2.6.29, lxc is fully functional".


-- 
 .
..: Lucian
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] clone.2: remove forward reference to 2.6.28

[Michael Kerrisk]

On Sun, Oct 24, 2010 at 6:13 PM, Lucian Adrian Grijincu
<lucian.grijincu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Sun, Oct 24, 2010 at 5:42 PM, Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> I am reluctant to apply this patch, since it would be more useful to
>> document exactly when the implementation was completed. Would you be
>> able to determine this information and resubmit the patch?
>
> In http://lxc.sourceforge.net/man/lxc.html they say: "With the kernel
> 2.6.29, lxc is fully functional".

Lucian,

I applied the patch below, for man-pages-3.30.

Alexey, Pavel, Eric,pulling your names from the git logs, it looks
like you might be able to answer the question: by which kernel version
did the CLONE_NEWNET implementation become complete? We suppose it is
2.6.29, but it would be good to have confirmation

Cheers,

Michael


diff --git a/man2/clone.2 b/man2/clone.2
index a126a05..eadec90 100644
--- a/man2/clone.2
+++ b/man2/clone.2
@@ -288,8 +288,8 @@ This flag can't be specified in conjunction with
 .BR CLONE_SYSVSEM .
 .TP
 .BR CLONE_NEWNET " (since Linux 2.6.24)"
-(The implementation of this flag is not yet complete,
-but probably will be mostly complete by about Linux 2.6.28.)
+(The implementation of this flag was only completed
+by about kernel version 2.6.29.)

 If
 .B CLONE_NEWNET


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] clone.2: remove forward reference to 2.6.28

[Alexey Dobriyan]

On Sat, Oct 30, 2010 at 08:11:28AM +0200, Michael Kerrisk wrote:
> by which kernel version did the CLONE_NEWNET implementation become complete?
> We suppose it is 2.6.29, but it would be good to have confirmation

In my book, this is 2.6.33 where netns XFRM became usable. :-)

commit d7c7544c3d5f59033d1bf3236bc7b289f5f26b75
Author: Alexey Dobriyan <adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date:   Sun Jan 24 22:47:53 2010 -0800

    netns xfrm: deal with dst entries in netns
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] unshare.2: Document CLONE_NEWNET

[Michael Kerrisk]

Hello Lucian,

On Fri, Oct 15, 2010 at 3:25 AM, Lucian Adrian Grijincu
<lucian.grijincu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Signed-off-by: Lucian Adrian Grijincu <lucian.grijincu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>  man2/unshare.2 |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/man2/unshare.2 b/man2/unshare.2
> index 051ebf5..2e43806 100644
> --- a/man2/unshare.2
> +++ b/man2/unshare.2
> @@ -93,6 +93,10 @@ its namespace which is not shared with any other process.
>  Specifying this flag automatically implies
>  .B CLONE_FS
>  as well.
> +.TP
> +.B CLONE_NEWNET " (since Linux 2.6.24)"
> +Unshare the old network namespace. Specifying this flag
> +will move the process into a new network namespace.
>  .\" As at 2.6.16, the following forced implications also apply,
>  .\" although the relevant flags are not yet implemented.
>  .\" If CLONE_THREAD is set force CLONE_VM.
> --
> 1.7.1

Thanks for this proposal. I went with something a bit more consistent
with flags already documented, and also included the kernel version
number and capability requirements. Does it look okay to you?

Cheers,

Michael

--- a/man2/unshare.2
+++ b/man2/unshare.2
@@ -89,6 +89,19 @@ requires the
 .BR CAP_SYS_ADMIN
 capability.
 .TP
+.BR CLONE_NEWNET " (since Linux 2.6.24)
+This flag has the same effect as the
+.BR clone (2)
+.B CLONE_NEWNET
+flag.
+Unshare the network namespace,
+so that the calling process has a private copy of the
+network namespace which is not shared with any other process.
+.BR CLONE_NEWNET
+requires the
+.BR CAP_SYS_ADMIN
+capability.
+.TP
 .B CLONE_NEWNS
 .\" These flag name are inconsistent:
 .\" CLONE_NEWNS does the same thing in clone(), but CLONE_VM,



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] unshare.2: Document CLONE_NEWNET

[Lucian Adrian Grijincu]

Hi Michael,

On Sun, Oct 24, 2010 at 5:35 PM, Michael Kerrisk <mtk.manpages-Re5JQEeQqe8@public.gmane.orgm> wrote:
> +Unshare the network namespace,
> +so that the calling process has a private copy of the
> +network namespace

That's not exactly right. This is not a private copy of the network
namespace, as that would mean I'd have all devices available in the
new network namespace, but changes done in my private copy will not be
visible to others. This creates a new network namespace from scratch.
You don't have anything from the old network namespace in the new one.
Even the loopback device is new.


> which is not shared with any other process.

It's not shared with previously existing processes. Child processes
will, by default, inherit the network namespace.


How does this one look?

diff --git a/man2/unshare.2 b/man2/unshare.2
index 051ebf5..49377c5 100644
--- a/man2/unshare.2
+++ b/man2/unshare.2
@@ -76,6 +76,22 @@ or umask attributes with any other process.
 or
 .BR umask (2)
 .TP
+.BR CLONE_NEWNET " (since Linux 2.6.24)
+This flag has the
+.I same
+effect as the
+.BR clone (2)
+.B CLONE_NEWNET
+flag.
+Unshare the network namespace,
+so that the calling process is moved into a
+new network namespace which is not shared
+with any previous process.
+.BR CLONE_NEWNET
+requires the
+.BR CAP_SYS_ADMIN
+capability.
+.TP
 .B CLONE_NEWNS
 .\" These flag name are inconsistent:
 .\" CLONE_NEWNS does the same thing in clone(), but CLONE_VM,

-- 
 .
..: Lucian
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] unshare.2: Document CLONE_NEWNET

[Michael Kerrisk]

Hello Lucian,

On Sun, Oct 24, 2010 at 6:06 PM, Lucian Adrian Grijincu
<lucian.grijincu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Michael,
>
> On Sun, Oct 24, 2010 at 5:35 PM, Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>> +Unshare the network namespace,
>> +so that the calling process has a private copy of the
>> +network namespace
>
> That's not exactly right. This is not a private copy of the network
> namespace, as that would mean I'd have all devices available in the
> new network namespace, but changes done in my private copy will not be
> visible to others. This creates a new network namespace from scratch.
> You don't have anything from the old network namespace in the new one.
> Even the loopback device is new.

Thanks for checking this!

>> which is not shared with any other process.
>
> It's not shared with previously existing processes. Child processes
> will, by default, inherit the network namespace.
>
>
> How does this one look?

Much better.

> diff --git a/man2/unshare.2 b/man2/unshare.2
> index 051ebf5..49377c5 100644
> --- a/man2/unshare.2
> +++ b/man2/unshare.2
> @@ -76,6 +76,22 @@ or umask attributes with any other process.
>  or
>  .BR umask (2)
>  .TP
> +.BR CLONE_NEWNET " (since Linux 2.6.24)
> +This flag has the
> +.I same
> +effect as the
> +.BR clone (2)
> +.B CLONE_NEWNET
> +flag.
> +Unshare the network namespace,
> +so that the calling process is moved into a
> +new network namespace which is not shared
> +with any previous process.
> +.BR CLONE_NEWNET
> +requires the
> +.BR CAP_SYS_ADMIN
> +capability.
> +.TP
>  .B CLONE_NEWNS
>  .\" These flag name are inconsistent:
>  .\" CLONE_NEWNS does the same thing in clone(), but CLONE_VM,

Applied for man-pages-3.30 (but, I changed "previous" to "previously existing").

Thanks,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html