Bug 1452368

+++ This bug was initially created as a clone of Bug #1377583 +++

Description of problem:
The clone(2) man page for the clone syscall is missing information on the ENOSPC error that may be returned due to new user_namespaces(7) features.

From http://man7.org/linux/man-pages/man2/clone.2.html

       CLONE_NEWUSER
              (This flag first became meaningful for clone() in Linux
              2.6.23, the current clone() semantics were merged in Linux
              3.5, and the final pieces to make the user namespaces
              completely usable were merged in Linux 3.8.)

              If CLONE_NEWUSER is set, then create the process in a new user
              namespace.  If this flag is not set, then (as with fork(2))
              the process is created in the same user namespace as the
              calling process.

              For further information on user namespaces, see namespaces(7)
              and user_namespaces(7)

              Before Linux 3.8, use of CLONE_NEWUSER required that the
              caller have three capabilities: CAP_SYS_ADMIN, CAP_SETUID, and
              CAP_SETGID.  Starting with Linux 3.8, no privileges are needed
              to create a user namespace.

              This flag can't be specified in conjunction with CLONE_THREAD
              or CLONE_PARENT.  For security reasons, CLONE_NEWUSER cannot
              be specified in conjunction with CLONE_FS.

              For further information on user namespaces, see
              user_namespaces(7).

       ...

       ENOSPC (since Linux 3.7)
              CLONE_NEWPID was specified in flags, but the limit on the
              nesting depth of PID namespaces would have been exceeded; see
              pid_namespaces(7).

       ENOSPC (since Linux 4.9; beforehand EUSERS)
              CLONE_NEWUSER was specified in flags, and the call would cause
              the limit on the number of nested user namespaces to be
              exceeded.  See user_namespaces(7).

              From Linux 3.11 to Linux 4.8, the error diagnosed in this case
              was EUSERS.

       ENOSPC (since Linux 4.9)
              One of the values in flags specified the creation of a new
              user namespace, but doing so would have caused the limit
              defined by the corresponding file in /proc/sys/user to be
              exceeded.  For further details, see namespaces(7).

       ...

       EPERM  CLONE_NEWUSER was specified in flags, but either the effective
              user ID or the effective group ID of the caller does not have
              a mapping in the parent namespace (see user_namespaces(7)).


Version-Release number of selected component (if applicable):
man-pages-3.53-5.el7.noarch
man-pages-overrides-7.4.1-1.el7.x86_64


How reproducible:
always

Steps to Reproduce:
1. man 2 clone

Actual results:
no description of ENOSPC errors

Expected results:
ENOSPC is documented along with other user namespace features

Additional info:
Google Chrome 58 fails to start on RHEL 7.4 Beta due to these changes, and strace shows it's because clone() is returning ENOSPC:

$ strace google-chrome
...
clone(child_stack=0x7ffed21e4540, flags=CLONE_NEWUSER|SIGCHLD) = -1 ENOSPC (No space left on device)
--- SIGTRAP {si_signo=SIGTRAP, si_code=SI_KERNEL} ---
+++ killed by SIGTRAP (core dumped) +++
Trace/breakpoint trap (core dumped)

I checked the clone(2) man page to see what might cause ENOSPC and could not find any info on ENOSPC.