nice.2: Add mention of RLIMIT_NICE

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

signal.7: tfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

getrlimit.2: Refer to sched(7) in discussion of RLIMIT_RTPRIO and RLIMIT_RTTIME

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

getrlimit.2: SEE ALSO: add credentials(7)

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

getrlimit.2: refer to sched(7) in the discussion of RLIMIT_NICE

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

getrlimit.2: Minor wording fix for RLIMIT_NICE

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

getrlimit.2: Describe the range of the RLIMIT_NICE limit

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

setsid.2: SEE ALSO: add sched(7)

List sched(7), because setsid(2) is part of the machinery
of autogrouping.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

bpf.2: tfix

Changed to "will" instead of "with".

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

nice.2: Warn that autogrouping voids the effect of 'nice' in many cases

Refer the reader to sched(7) for the details.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

getpriority.2: Warn that autogrouping voids the effect of 'nice' in many cases

Refer the reader to sched(7) for the details.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Clarify that autogroup defaults on in various distros

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Note command that can be used to modify the autogroup nice value

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Improve section on nice value and group scheduling

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Relocate discussion of group scheduling

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Clarify details of autogroup nice value

Also clarify its interactions with the thread nice value.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: srcfix: tfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Further clarify scheduling policies for which autogroup applied

Further clarify that autogroup groups only SCHED_OTHER/SCHED_NICE/
SCHED_IDLE processes.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Add a subsection on group scheduling

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Tweak description of cgroups overriding autogroup

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: tfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Note error that occurs when writing invalid value to /proc/PID/autogroup

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Further clarify details of group scheduling

After comments by Mike Galbraith.

Reported-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: wfix

Reported-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: srcfix: add details to FIXME

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Rework discussion of autogroups

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Rework discussion of autogroup nice value

Remove the text saying that setting the autogroup nice value
always lowers the group's priority. That was actually a
bug introduced in Linux 4.7.

Also make it clearer that the autogroup nice value has the same
meaning as the nice value set by setpriority(2).

Reported-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

proc.5: Add pointers to sched(7) for autogroup files

sched(7) describes /proc/sys/kernel/sched_autogroup_enabled
and /proc/PID/autogroup.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Document the autogroup feature

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

getpriority.2: The nice value supplied to setpriority() is clamped

Note that the nice value supplied to setpriority() is clamped
to the permitted range.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

namespaces.7: srcfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Minor wording fix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

elf.5: Minor fixes

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

elf.5: Minor fixes

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

elf(5): Further details on Notes

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Minor rewording of discussion of nice value

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Add nice(2), getpriority(2), and setpriority(2) to API list

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

nice.2: Clarify that nice() changes the nice value of the calling *thread*

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

getpriority.2: Expand discussion of getpriority() return value

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

getpriority.2: Improve description of setpriority() return value

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Minor text reorganization

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: wfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Add a new introductory paragraph describing the nice value

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

random.7: tfix

Signed-off-by: Jakub Wilk <jwilk@jwilk.net>

ptrace.2: tfix

Signed-off-by: Jakub Wilk <jwilk@jwilk.net>

getrlimit.2: ffix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Mention RLIMIT_NICE in the discussion of the nice value

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched_setattr.2: Fix cross reference for further info on the nice value

The information moved from getpriority(2) to sched(7).

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

nice.2: add reference to sched(7) for further details on the nice value

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Add more precise details on CFS's treatment of the nice value

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

getpriority.2, sched.7: Move nice value details from getpriority(2) to sched(7)

Centralizing these details in sched(7) is more logical.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

getpriority.2: Minor wording change

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

getpriority.2: Minor wording fix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

nice.2: Add "C library/kernel differences" subsection heading

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

nice.2: Clarify the range of the nice value, and note that it is clamped

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

getpriority.2: The nice value supplied to setpriority() is clamped

Note that the nice value supplied to setpriority() is clamped
to the permitted range.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: ffix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Make it clearer that SCHED_OTHER is always scheduled below real-time

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Add introductory sentence mentioning CFS scheduler

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Minor wording improvement in text introducing system calls

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Remove mention of individual kernel developer names

It's not the norm to name developers of particular features
in each man page.  No need for an exception here.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Minor wording fix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: wfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

cgroups.7: Add details on 'cpu' CFS bandwidth control

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

elf.5: wfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

elf.5: srcfix: rewrap some long source lines

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

elf.5: A few tweaks to Mike Frysinger's text (Mike to check)

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

elf.5: Minor fixes to Mike Frysinger's patch

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

elf(5): document notes

Document the Elf{32,64}_Nhdr structure, the sections/segments that
contain notes, and how to interpret them.  I've been lazy and only
included the GNU extensions here, especially as others are not
defined in the elf.h header file as shipped by glibc.

I've mostly used binutils, glibc, breakpad, and the GABI ELF spec
as sources of data for these fields.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

setsid.2: Improve wording of text on calling setsid() after fork()+_exit()

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

random.7: srcfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

random.7: Remove recommendation against consuming large amounts of randomness

From the email discussion:

> >    Usage recommendations
> >        The kernel random-number generator relies on  entropy  gathered
> >        from  device  drivers and other sources of environmental noise.
> >        It is designed to produce a small amount of  high-quality  seed
> >        material to seed a cryptographically secure pseudorandom number
> >        generator (CSPRNG).  It is designed for  security,  not  speed,
> >        and  is  poorly  suited  to generating large amounts of crypto‐
> >        graphic random data.  Users should be economical in the  amount
> >        of seed material that they consume via getrandom(2), /dev/uran‐
> >        dom, and /dev/random.
> >
> >        ┌─────────────────────────────────────────────────────┐
> >        │FIXME                                                │
> >        ├─────────────────────────────────────────────────────┤
> >        │Is it really  necessary  to  avoid  consuming  large │
> >        │amounts from /dev/urandom? Various sources linked to │
> >        │by https://bugzilla.kernel.org/show_bug.cgi?id=71211 │
> >        │suggest it is not.                                   │
> >        │                                                     │
> >        │And: has the answer to the previous question changed │
> >        │across kernel versions?                              │
> >        └─────────────────────────────────────────────────────┘
> >        Consuming unnecessarily large  quantities  of  data  via  these
> >        interfaces  will  have  a negative impact on other consumers of
> >        randomness.

[Ted T'so:]

> So "poorly suited" is definitely true.  Also true is that urandom is
> not engineered for use for non-cryptographic uses.  It's always going
> to be faster to use random(3) for those purposes.
>
> As far as whether or not it has a negative impact, it depends on how
> much you trust the underlying cryptographic algorithms.  If the CSPRNG
> is seeded correctly with at least 256 bits of entropy that can't be
> guessed by the attacker, and if the underlying cryptographic
> primitives are secure, then it won't matter.  But *if* there is an
> unknown vulnerability in the underlying primitive, and *if* large
> amounts of data generated by the CSPRNG would help exploit that
> vulnerability, and *if* that bulk amount of CSPRNG output is made
> available to an attacker with the capability to break the underlying
> cryptographic vulnerability, then there would be a problem.
>
> Obviously, no one knows of such a vulnerability, and I'm fairly
> confident that there won't be such a vulnerability across the
> different ways we've used to generate the urandom source --- but some
> people are professional paranoids, and would argue that we shouldn't
> make bulk output of the CSPRNG available for no good reason, just in
> case.

[Nikos Mavrogiannopoulos:]

The above is certainly accurate, however, I think that such a
discussion or text, when reflected to a man-page is going to
cause problems. The audience of a man-page are not crypto people,
and seeing such text would create confusion rather than clarify
how these devices/apis should be used. The *if* part is not put
into a perspective, suggesting that such an *if* is possible.
However, if one clarifies, i.e., in that case, your TLS or SSH
connection is most likely broken as well, and not because of any
attack on /dev/urandom, then one can see that we are heading
towards a theoretical discussion.

My suggestion, on that particular text would be to remove it,
but make it explicit somewhere in the text that all the
assurances for the devices depend on the crypto primitives,
rather than describing risks that may arise on particular
usage patterns *if* primitives are broken.

Reviewed-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
Reported-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

fideduperange.2: Fix the discussion of maximum sizes

Fix the discussion of the limitations on the dest_count and
src_length parameters to the fideduperange ioctl() to reflect
what's actually in the kernel.

Reviewed-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>

mbsnrtowcs.3: Note behavior of mbsnrtowcs() for an incomplete character

Note the behavior of mbsnrtowcs() when an incomplete character
is found at end of the input buffer.

Reported-by: Igor Liferenko <igor.liferenko@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

mbsnrtowcs.3: wfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: tfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

proc.5: tfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: tfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: Give the page a more generic NAME

The page isn't just about APIs.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

sched.7: NOTES: mention cgroups CPU controller

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

reboot.2: wfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

reboot.2: Note errors for invalid commands inside a PID namespace

Signed-off-by: Wang Long <long.wanglong@huawei.com>

timerfd_create.2: Document TFD_TIMER_CANCEL_ON_SET

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

timerfd_create.2: Rework discussion on relative and absolute timers

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

timerfd_create.2: Document CLOCK_BOOTTIME, CLOCK_REALTIME_ALARM, and CLOCK_BOOTTIME_ALARM

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

timer_create.2: srcfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

timerfd_create.2: Rework description of clocks as a hanging list

Done in part as preparation for following patches.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

clock_getres.2: tfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

clock_getres.2: wfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

timer_create.2: Document CLOCK_REALTIME_ALARM and CLOCK_BOOTTIME_ALARM

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

timer_create.2: Document CLOCK_BOOTTIME

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

signalfd.2: Document ssi_addr_lsb field of signalfd_siginfo

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

signalfd.2: ffix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

isalpha.3: tfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

mbstowcs.3: Add missing include to example program

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845172

Reported-by: Igor Liferenko <igor.liferenko@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

mmap.2: Add (much) more detail on MAP_GROWSDOWN

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

mmap.2: wfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

mprotect.2: tfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

mprotect.2: wfix

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

mprotect.2: Various fixes to Eugene Syromyatnikov's text

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>