Adding upstream version 4.22.0.upstream/4.22.0

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 854 insertions, 0 deletions

diff --git a/upstream/debian-unstable/man2/getrlimit.2 b/upstream/debian-unstable/man2/getrlimit.2
new file mode 100644
index 00000000..afc2c229
--- /dev/null
+++ b/upstream/debian-unstable/man2/getrlimit.2
@@ -0,0 +1,854 @@
+'\" t
+.\" Copyright (c) 1992 Drew Eckhardt, March 28, 1992
+.\" and Copyright (c) 2002, 2004, 2005, 2008, 2010 Michael Kerrisk
+.\"
+.\" SPDX-License-Identifier: Linux-man-pages-copyleft
+.\"
+.\" Modified by Michael Haardt <michael@moria.de>
+.\" Modified 1993-07-23 by Rik Faith <faith@cs.unc.edu>
+.\" Modified 1996-01-13 by Arnt Gulbrandsen <agulbra@troll.no>
+.\" Modified 1996-01-22 by aeb, following a remark by
+.\"          Tigran Aivazian <tigran@sco.com>
+.\" Modified 1996-04-14 by aeb, following a remark by
+.\"          Robert Bihlmeyer <robbe@orcus.ping.at>
+.\" Modified 1996-10-22 by Eric S. Raymond <esr@thyrsus.com>
+.\" Modified 2001-05-04 by aeb, following a remark by
+.\"          Håvard Lygre <hklygre@online.no>
+.\" Modified 2001-04-17 by Michael Kerrisk <mtk.manpages@gmail.com>
+.\" Modified 2002-06-13 by Michael Kerrisk <mtk.manpages@gmail.com>
+.\"     Added note on nonstandard behavior when SIGCHLD is ignored.
+.\" Modified 2002-07-09 by Michael Kerrisk <mtk.manpages@gmail.com>
+.\"	Enhanced descriptions of 'resource' values
+.\" Modified 2003-11-28 by aeb, added RLIMIT_CORE
+.\" Modified 2004-03-26 by aeb, added RLIMIT_AS
+.\" Modified 2004-06-16 by Michael Kerrisk <mtk.manpages@gmail.com>
+.\"     Added notes on CAP_SYS_RESOURCE
+.\"
+.\" 2004-11-16 -- mtk: the getrlimit.2 page, which formally included
+.\" coverage of getrusage(2), has been split, so that the latter
+.\" is now covered in its own getrusage.2.
+.\"
+.\" Modified 2004-11-16, mtk: A few other minor changes
+.\" Modified 2004-11-23, mtk
+.\"	Added notes on RLIMIT_MEMLOCK, RLIMIT_NPROC, and RLIMIT_RSS
+.\"		to "CONFORMING TO"
+.\" Modified 2004-11-25, mtk
+.\"	Rewrote discussion on RLIMIT_MEMLOCK to incorporate kernel
+.\"		2.6.9 changes.
+.\"	Added note on RLIMIT_CPU error in older kernels
+.\" 2004-11-03, mtk, Added RLIMIT_SIGPENDING
+.\" 2005-07-13, mtk, documented RLIMIT_MSGQUEUE limit.
+.\" 2005-07-28, mtk, Added descriptions of RLIMIT_NICE and RLIMIT_RTPRIO
+.\" 2008-05-07, mtk / Peter Zijlstra, Added description of RLIMIT_RTTIME
+.\" 2010-11-06, mtk: Added documentation of prlimit()
+.\"
+.TH getrlimit 2 2023-07-20 "Linux man-pages 6.05.01"
+.SH NAME
+getrlimit, setrlimit, prlimit \- get/set resource limits
+.SH LIBRARY
+Standard C library
+.RI ( libc ", " \-lc )
+.SH SYNOPSIS
+.nf
+.B #include <sys/resource.h>
+.PP
+.BI "int getrlimit(int " resource ", struct rlimit *" rlim );
+.BI "int setrlimit(int " resource ", const struct rlimit *" rlim );
+.PP
+.BI "int prlimit(pid_t "  pid ", int " resource ,
+.BI "            const struct rlimit *_Nullable " new_limit ,
+.BI "            struct rlimit *_Nullable " old_limit );
+.fi
+.PP
+.RS -4
+Feature Test Macro Requirements for glibc (see
+.BR feature_test_macros (7)):
+.RE
+.PP
+.BR prlimit ():
+.nf
+    _GNU_SOURCE
+.fi
+.SH DESCRIPTION
+The
+.BR getrlimit ()
+and
+.BR setrlimit ()
+system calls get and set resource limits.
+Each resource has an associated soft and hard limit, as defined by the
+.I rlimit
+structure:
+.PP
+.in +4n
+.EX
+struct rlimit {
+    rlim_t rlim_cur;  /* Soft limit */
+    rlim_t rlim_max;  /* Hard limit (ceiling for rlim_cur) */
+};
+.EE
+.in
+.PP
+The soft limit is the value that the kernel enforces for the
+corresponding resource.
+The hard limit acts as a ceiling for the soft limit:
+an unprivileged process may set only its soft limit to a value in the
+range from 0 up to the hard limit, and (irreversibly) lower its hard limit.
+A privileged process (under Linux: one with the
+.B CAP_SYS_RESOURCE
+capability in the initial user namespace)
+may make arbitrary changes to either limit value.
+.PP
+The value
+.B RLIM_INFINITY
+denotes no limit on a resource (both in the structure returned by
+.BR getrlimit ()
+and in the structure passed to
+.BR setrlimit ()).
+.PP
+The
+.I resource
+argument must be one of:
+.TP
+.B RLIMIT_AS
+This is the maximum size of the process's virtual memory
+(address space).
+The limit is specified in bytes, and is rounded down to the system page size.
+.\" since Linux 2.0.27 / Linux 2.1.12
+This limit affects calls to
+.BR brk (2),
+.BR mmap (2),
+and
+.BR mremap (2),
+which fail with the error
+.B ENOMEM
+upon exceeding this limit.
+In addition, automatic stack expansion fails
+(and generates a
+.B SIGSEGV
+that kills the process if no alternate stack
+has been made available via
+.BR sigaltstack (2)).
+Since the value is a \fIlong\fP, on machines with a 32-bit \fIlong\fP
+either this limit is at most 2\ GiB, or this resource is unlimited.
+.TP
+.B RLIMIT_CORE
+This is the maximum size of a
+.I core
+file (see
+.BR core (5))
+in bytes that the process may dump.
+When 0 no core dump files are created.
+When nonzero, larger dumps are truncated to this size.
+.TP
+.B RLIMIT_CPU
+This is a limit, in seconds,
+on the amount of CPU time that the process can consume.
+When the process reaches the soft limit, it is sent a
+.B SIGXCPU
+signal.
+The default action for this signal is to terminate the process.
+However, the signal can be caught, and the handler can return control to
+the main program.
+If the process continues to consume CPU time, it will be sent
+.B SIGXCPU
+once per second until the hard limit is reached, at which time
+it is sent
+.BR SIGKILL .
+(This latter point describes Linux behavior.
+Implementations vary in how they treat processes which continue to
+consume CPU time after reaching the soft limit.
+Portable applications that need to catch this signal should
+perform an orderly termination upon first receipt of
+.BR SIGXCPU .)
+.TP
+.B RLIMIT_DATA
+This is the maximum size
+of the process's data segment (initialized data,
+uninitialized data, and heap).
+The limit is specified in bytes, and is rounded down to the system page size.
+This limit affects calls to
+.BR brk (2),
+.BR sbrk (2),
+and (since Linux 4.7)
+.BR mmap (2),
+.\" commits 84638335900f1995495838fe1bd4870c43ec1f67
+.\" ("mm: rework virtual memory accounting"),
+.\" f4fcd55841fc9e46daac553b39361572453c2b88
+.\" (mm: enable RLIMIT_DATA by default with workaround for valgrind).
+which fail with the error
+.B ENOMEM
+upon encountering the soft limit of this resource.
+.TP
+.B RLIMIT_FSIZE
+This is the maximum size in bytes of files that the process may create.
+Attempts to extend a file beyond this limit result in delivery of a
+.B SIGXFSZ
+signal.
+By default, this signal terminates a process, but a process can
+catch this signal instead, in which case the relevant system call (e.g.,
+.BR write (2),
+.BR truncate (2))
+fails with the error
+.BR EFBIG .
+.TP
+.BR RLIMIT_LOCKS " (Linux 2.4.0 to Linux 2.4.24)"
+.\" to be precise: Linux 2.4.0-test9; no longer in Linux 2.4.25 / Linux 2.5.65
+This is a limit on the combined number of
+.BR flock (2)
+locks and
+.BR fcntl (2)
+leases that this process may establish.
+.TP
+.B RLIMIT_MEMLOCK
+This is the maximum number of bytes of memory that may be locked
+into RAM.
+This limit is in effect rounded down to the nearest multiple
+of the system page size.
+This limit affects
+.BR mlock (2),
+.BR mlockall (2),
+and the
+.BR mmap (2)
+.B MAP_LOCKED
+operation.
+Since Linux 2.6.9, it also affects the
+.BR shmctl (2)
+.B SHM_LOCK
+operation, where it sets a maximum on the total bytes in
+shared memory segments (see
+.BR shmget (2))
+that may be locked by the real user ID of the calling process.
+The
+.BR shmctl (2)
+.B SHM_LOCK
+locks are accounted for separately from the per-process memory
+locks established by
+.BR mlock (2),
+.BR mlockall (2),
+and
+.BR mmap (2)
+.BR MAP_LOCKED ;
+a process can lock bytes up to this limit in each of these
+two categories.
+.IP
+Before Linux 2.6.9, this limit controlled the amount of
+memory that could be locked by a privileged process.
+Since Linux 2.6.9, no limits are placed on the amount of memory
+that a privileged process may lock, and this limit instead governs
+the amount of memory that an unprivileged process may lock.
+.TP
+.BR RLIMIT_MSGQUEUE " (since Linux 2.6.8)"
+This is a limit on the number of bytes that can be allocated
+for POSIX message queues for the real user ID of the calling process.
+This limit is enforced for
+.BR mq_open (3).
+Each message queue that the user creates counts (until it is removed)
+against this limit according to the formula:
+.RS 4
+.IP
+Since Linux 3.5:
+.IP
+.in +4n
+.EX
+bytes = attr.mq_maxmsg * sizeof(struct msg_msg) +
+        MIN(attr.mq_maxmsg, MQ_PRIO_MAX) *
+              sizeof(struct posix_msg_tree_node)+
+                        /* For overhead */
+        attr.mq_maxmsg * attr.mq_msgsize;
+                        /* For message data */
+.EE
+.in
+.IP
+Linux 3.4 and earlier:
+.IP
+.in +4n
+.EX
+bytes = attr.mq_maxmsg * sizeof(struct msg_msg *) +
+                        /* For overhead */
+        attr.mq_maxmsg * attr.mq_msgsize;
+                        /* For message data */
+.EE
+.in
+.RE
+.IP
+where
+.I attr
+is the
+.I mq_attr
+structure specified as the fourth argument to
+.BR mq_open (3),
+and the
+.I msg_msg
+and
+.I posix_msg_tree_node
+structures are kernel-internal structures.
+.IP
+The "overhead" addend in the formula accounts for overhead
+bytes required by the implementation
+and ensures that the user cannot
+create an unlimited number of zero-length messages (such messages
+nevertheless each consume some system memory for bookkeeping overhead).
+.TP
+.BR RLIMIT_NICE " (since Linux 2.6.12, but see BUGS below)"
+This specifies a ceiling to which the process's nice value can be raised using
+.BR setpriority (2)
+or
+.BR nice (2).
+The actual ceiling for the nice value is calculated as
+.IR "20\ \-\ rlim_cur" .
+The useful range for this limit is thus from 1
+(corresponding to a nice value of 19) to 40
+(corresponding to a nice value of \-20).
+This unusual choice of range was necessary
+because negative numbers cannot be specified
+as resource limit values, since they typically have special meanings.
+For example,
+.B RLIM_INFINITY
+typically is the same as \-1.
+For more detail on the nice value, see
+.BR sched (7).
+.TP
+.B RLIMIT_NOFILE
+This specifies a value one greater than the maximum file descriptor number
+that can be opened by this process.
+Attempts
+.RB ( open (2),
+.BR pipe (2),
+.BR dup (2),
+etc.)
+to exceed this limit yield the error
+.BR EMFILE .
+(Historically, this limit was named
+.B RLIMIT_OFILE
+on BSD.)
+.IP
+Since Linux 4.5,
+this limit also defines the maximum number of file descriptors that
+an unprivileged process (one without the
+.B CAP_SYS_RESOURCE
+capability) may have "in flight" to other processes,
+by being passed across UNIX domain sockets.
+This limit applies to the
+.BR sendmsg (2)
+system call.
+For further details, see
+.BR unix (7).
+.TP
+.B RLIMIT_NPROC
+This is a limit on the number of extant process
+(or, more precisely on Linux, threads)
+for the real user ID of the calling process.
+So long as the current number of processes belonging to this
+process's real user ID is greater than or equal to this limit,
+.BR fork (2)
+fails with the error
+.BR EAGAIN .
+.IP
+The
+.B RLIMIT_NPROC
+limit is not enforced for processes that have either the
+.B CAP_SYS_ADMIN
+or the
+.B CAP_SYS_RESOURCE
+capability,
+or run with real user ID 0.
+.TP
+.B RLIMIT_RSS
+This is a limit (in bytes) on the process's resident set
+(the number of virtual pages resident in RAM).
+This limit has effect only in Linux 2.4.x, x < 30, and there
+affects only calls to
+.BR madvise (2)
+specifying
+.BR MADV_WILLNEED .
+.\" As at Linux 2.6.12, this limit still does nothing in Linux 2.6 though
+.\" talk of making it do something has surfaced from time to time in LKML
+.\"       -- MTK, Jul 05
+.TP
+.BR RLIMIT_RTPRIO " (since Linux 2.6.12, but see BUGS)"
+This specifies a ceiling on the real-time priority that may be set for
+this process using
+.BR sched_setscheduler (2)
+and
+.BR sched_setparam (2).
+.IP
+For further details on real-time scheduling policies, see
+.BR sched (7)
+.TP
+.BR RLIMIT_RTTIME " (since Linux 2.6.25)"
+This is a limit (in microseconds)
+on the amount of CPU time that a process scheduled
+under a real-time scheduling policy may consume without making a blocking
+system call.
+For the purpose of this limit,
+each time a process makes a blocking system call,
+the count of its consumed CPU time is reset to zero.
+The CPU time count is not reset if the process continues trying to
+use the CPU but is preempted, its time slice expires, or it calls
+.BR sched_yield (2).
+.IP
+Upon reaching the soft limit, the process is sent a
+.B SIGXCPU
+signal.
+If the process catches or ignores this signal and
+continues consuming CPU time, then
+.B SIGXCPU
+will be generated once each second until the hard limit is reached,
+at which point the process is sent a
+.B SIGKILL
+signal.
+.IP
+The intended use of this limit is to stop a runaway
+real-time process from locking up the system.
+.IP
+For further details on real-time scheduling policies, see
+.BR sched (7)
+.TP
+.BR RLIMIT_SIGPENDING " (since Linux 2.6.8)"
+This is a limit on the number of signals
+that may be queued for the real user ID of the calling process.
+Both standard and real-time signals are counted for the purpose of
+checking this limit.
+However, the limit is enforced only for
+.BR sigqueue (3);
+it is always possible to use
+.BR kill (2)
+to queue one instance of any of the signals that are not already
+queued to the process.
+.\" This replaces the /proc/sys/kernel/rtsig-max system-wide limit
+.\" that was present in Linux <= 2.6.7.  MTK Dec 04
+.TP
+.B RLIMIT_STACK
+This is the maximum size of the process stack, in bytes.
+Upon reaching this limit, a
+.B SIGSEGV
+signal is generated.
+To handle this signal, a process must employ an alternate signal stack
+.RB ( sigaltstack (2)).
+.IP
+Since Linux 2.6.23,
+this limit also determines the amount of space used for the process's
+command-line arguments and environment variables; for details, see
+.BR execve (2).
+.SS prlimit()
+.\" commit c022a0acad534fd5f5d5f17280f6d4d135e74e81
+.\" Author: Jiri Slaby <jslaby@suse.cz>
+.\" Date:   Tue May 4 18:03:50 2010 +0200
+.\"
+.\"     rlimits: implement prlimit64 syscall
+.\"
+.\" commit 6a1d5e2c85d06da35cdfd93f1a27675bfdc3ad8c
+.\" Author: Jiri Slaby <jslaby@suse.cz>
+.\" Date:   Wed Mar 24 17:06:58 2010 +0100
+.\"
+.\"     rlimits: add rlimit64 structure
+.\"
+The Linux-specific
+.BR prlimit ()
+system call combines and extends the functionality of
+.BR setrlimit ()
+and
+.BR getrlimit ().
+It can be used to both set and get the resource limits of an arbitrary process.
+.PP
+The
+.I resource
+argument has the same meaning as for
+.BR setrlimit ()
+and
+.BR getrlimit ().
+.PP
+If the
+.I new_limit
+argument is not NULL, then the
+.I rlimit
+structure to which it points is used to set new values for
+the soft and hard limits for
+.IR resource .
+If the
+.I old_limit
+argument is not NULL, then a successful call to
+.BR prlimit ()
+places the previous soft and hard limits for
+.I resource
+in the
+.I rlimit
+structure pointed to by
+.IR old_limit .
+.PP
+The
+.I pid
+argument specifies the ID of the process on which the call is to operate.
+If
+.I pid
+is 0, then the call applies to the calling process.
+To set or get the resources of a process other than itself,
+the caller must have the
+.B CAP_SYS_RESOURCE
+capability in the user namespace of the process
+whose resource limits are being changed, or the
+real, effective, and saved set user IDs of the target process
+must match the real user ID of the caller
+.I and
+the real, effective, and saved set group IDs of the target process
+must match the real group ID of the caller.
+.\" FIXME . this permission check is strange
+.\" Asked about this on LKML, 7 Nov 2010
+.\"     "Inconsistent credential checking in prlimit() syscall"
+.SH RETURN VALUE
+On success, these system calls return 0.
+On error, \-1 is returned, and
+.I errno
+is set to indicate the error.
+.SH ERRORS
+.TP
+.B EFAULT
+A pointer argument points to a location
+outside the accessible address space.
+.TP
+.B EINVAL
+The value specified in
+.I resource
+is not valid;
+or, for
+.BR setrlimit ()
+or
+.BR prlimit ():
+.I rlim\->rlim_cur
+was greater than
+.IR rlim\->rlim_max .
+.TP
+.B EPERM
+An unprivileged process tried to raise the hard limit; the
+.B CAP_SYS_RESOURCE
+capability is required to do this.
+.TP
+.B EPERM
+The caller tried to increase the hard
+.B RLIMIT_NOFILE
+limit above the maximum defined by
+.I /proc/sys/fs/nr_open
+(see
+.BR proc (5))
+.TP
+.B EPERM
+.RB ( prlimit ())
+The calling process did not have permission to set limits
+for the process specified by
+.IR pid .
+.TP
+.B ESRCH
+Could not find a process with the ID specified in
+.IR pid .
+.SH ATTRIBUTES
+For an explanation of the terms used in this section, see
+.BR attributes (7).
+.TS
+allbox;
+lbx lb lb
+l l l.
+Interface	Attribute	Value
+T{
+.na
+.nh
+.BR getrlimit (),
+.BR setrlimit (),
+.BR prlimit ()
+T}	Thread safety	MT-Safe
+.TE
+.sp 1
+.SH STANDARDS
+.TP
+.BR getrlimit ()
+.TQ
+.BR setrlimit ()
+POSIX.1-2008.
+.TP
+.BR prlimit ()
+Linux.
+.PP
+.B RLIMIT_MEMLOCK
+and
+.B RLIMIT_NPROC
+derive from BSD and are not specified in POSIX.1;
+they are present on the BSDs and Linux, but on few other implementations.
+.B RLIMIT_RSS
+derives from BSD and is not specified in POSIX.1;
+it is nevertheless present on most implementations.
+.BR \%RLIMIT_MSGQUEUE ,
+.BR RLIMIT_NICE ,
+.BR RLIMIT_RTPRIO ,
+.BR RLIMIT_RTTIME ,
+and
+.B \%RLIMIT_SIGPENDING
+are Linux-specific.
+.SH HISTORY
+.TP
+.BR getrlimit ()
+.TQ
+.BR setrlimit ()
+POSIX.1-2001, SVr4, 4.3BSD.
+.TP
+.BR prlimit ()
+Linux 2.6.36,
+glibc 2.13.
+.SH NOTES
+A child process created via
+.BR fork (2)
+inherits its parent's resource limits.
+Resource limits are preserved across
+.BR execve (2).
+.PP
+Resource limits are per-process attributes that are shared
+by all of the threads in a process.
+.PP
+Lowering the soft limit for a resource below the process's
+current consumption of that resource will succeed
+(but will prevent the process from further increasing
+its consumption of the resource).
+.PP
+One can set the resource limits of the shell using the built-in
+.I ulimit
+command
+.RI ( limit
+in
+.BR csh (1)).
+The shell's resource limits are inherited by the processes that
+it creates to execute commands.
+.PP
+Since Linux 2.6.24, the resource limits of any process can be inspected via
+.IR /proc/ pid /limits ;
+see
+.BR proc (5).
+.PP
+Ancient systems provided a
+.BR vlimit ()
+function with a similar purpose to
+.BR setrlimit ().
+For backward compatibility, glibc also provides
+.BR vlimit ().
+All new applications should be written using
+.BR setrlimit ().
+.SS C library/kernel ABI differences
+Since glibc 2.13, the glibc
+.BR getrlimit ()
+and
+.BR setrlimit ()
+wrapper functions no longer invoke the corresponding system calls,
+but instead employ
+.BR prlimit (),
+for the reasons described in BUGS.
+.PP
+The name of the glibc wrapper function is
+.BR prlimit ();
+the underlying system call is
+.BR prlimit64 ().
+.SH BUGS
+In older Linux kernels, the
+.B SIGXCPU
+and
+.B SIGKILL
+signals delivered when a process encountered the soft and hard
+.B RLIMIT_CPU
+limits were delivered one (CPU) second later than they should have been.
+This was fixed in Linux 2.6.8.
+.PP
+In Linux 2.6.x kernels before Linux 2.6.17, a
+.B RLIMIT_CPU
+limit of 0 is wrongly treated as "no limit" (like
+.BR RLIM_INFINITY ).
+Since Linux 2.6.17, setting a limit of 0 does have an effect,
+but is actually treated as a limit of 1 second.
+.\" see http://marc.theaimsgroup.com/?l=linux-kernel&m=114008066530167&w=2
+.PP
+A kernel bug means that
+.\" See https://lwn.net/Articles/145008/
+.B RLIMIT_RTPRIO
+does not work in Linux 2.6.12; the problem is fixed in Linux 2.6.13.
+.PP
+In Linux 2.6.12, there was an off-by-one mismatch
+between the priority ranges returned by
+.BR getpriority (2)
+and
+.BR RLIMIT_NICE .
+This had the effect that the actual ceiling for the nice value
+was calculated as
+.IR "19\ \-\ rlim_cur" .
+This was fixed in Linux 2.6.13.
+.\" see http://marc.theaimsgroup.com/?l=linux-kernel&m=112256338703880&w=2
+.PP
+Since Linux 2.6.12,
+.\" The relevant patch, sent to LKML, seems to be
+.\" http://thread.gmane.org/gmane.linux.kernel/273462
+.\" From: Roland McGrath <roland <at> redhat.com>
+.\" Subject: [PATCH 7/7] make RLIMIT_CPU/SIGXCPU per-process
+.\" Date: 2005-01-23 23:27:46 GMT
+if a process reaches its soft
+.B RLIMIT_CPU
+limit and has a handler installed for
+.BR SIGXCPU ,
+then, in addition to invoking the signal handler,
+the kernel increases the soft limit by one second.
+This behavior repeats if the process continues to consume CPU time,
+until the hard limit is reached,
+at which point the process is killed.
+Other implementations
+.\" Tested Solaris 10, FreeBSD 9, OpenBSD 5.0
+do not change the
+.B RLIMIT_CPU
+soft limit in this manner,
+and the Linux behavior is probably not standards conformant;
+portable applications should avoid relying on this Linux-specific behavior.
+.\" FIXME . https://bugzilla.kernel.org/show_bug.cgi?id=50951
+The Linux-specific
+.B RLIMIT_RTTIME
+limit exhibits the same behavior when the soft limit is encountered.
+.PP
+Kernels before Linux 2.4.22 did not diagnose the error
+.B EINVAL
+for
+.BR setrlimit ()
+when
+.I rlim\->rlim_cur
+was greater than
+.IR rlim\->rlim_max .
+.\" d3561f78fd379a7110e46c87964ba7aa4120235c
+.PP
+Linux doesn't return an error when an attempt to set
+.B RLIMIT_CPU
+has failed, for compatibility reasons.
+.\"
+.SS Representation of """large""" resource limit values on 32-bit platforms
+The glibc
+.BR getrlimit ()
+and
+.BR setrlimit ()
+wrapper functions use a 64-bit
+.I rlim_t
+data type, even on 32-bit platforms.
+However, the
+.I rlim_t
+data type used in the
+.BR getrlimit ()
+and
+.BR setrlimit ()
+system calls is a (32-bit)
+.IR "unsigned long" .
+.\" Linux still uses long for limits internally:
+.\" c022a0acad534fd5f5d5f17280f6d4d135e74e81
+.\" kernel/sys.c:do_prlimit() still uses struct rlimit which
+.\" uses kernel_ulong_t for its members, i.e. 32-bit  on 32-bit kernel.
+Furthermore, in Linux,
+the kernel represents resource limits on 32-bit platforms as
+.IR "unsigned long" .
+However, a 32-bit data type is not wide enough.
+.\" https://bugzilla.kernel.org/show_bug.cgi?id=5042
+.\" https://www.sourceware.org/bugzilla/show_bug.cgi?id=12201
+The most pertinent limit here is
+.BR \%RLIMIT_FSIZE ,
+which specifies the maximum size to which a file can grow:
+to be useful, this limit must be represented using a type
+that is as wide as the type used to
+represent file offsets\[em]that is, as wide as a 64-bit
+.B off_t
+(assuming a program compiled with
+.IR _FILE_OFFSET_BITS=64 ).
+.PP
+To work around this kernel limitation,
+if a program tried to set a resource limit to a value larger than
+can be represented in a 32-bit
+.IR "unsigned long" ,
+then the glibc
+.BR setrlimit ()
+wrapper function silently converted the limit value to
+.BR RLIM_INFINITY .
+In other words, the requested resource limit setting was silently ignored.
+.PP
+Since glibc 2.13,
+.\" https://www.sourceware.org/bugzilla/show_bug.cgi?id=12201
+glibc works around the limitations of the
+.BR \%getrlimit ()
+and
+.BR setrlimit ()
+system calls by implementing
+.BR setrlimit ()
+and
+.BR \%getrlimit ()
+as wrapper functions that call
+.BR prlimit ().
+.SH EXAMPLES
+The program below demonstrates the use of
+.BR prlimit ().
+.PP
+.\" SRC BEGIN (getrlimit.c)
+.EX
+#define _GNU_SOURCE
+#define _FILE_OFFSET_BITS 64
+#include <err.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <sys/resource.h>
+#include <time.h>
+\&
+int
+main(int argc, char *argv[])
+{
+    pid_t          pid;
+    struct rlimit  old, new;
+    struct rlimit  *newp;
+\&
+    if (!(argc == 2 || argc == 4)) {
+        fprintf(stderr, "Usage: %s <pid> [<new\-soft\-limit> "
+                "<new\-hard\-limit>]\en", argv[0]);
+        exit(EXIT_FAILURE);
+    }
+\&
+    pid = atoi(argv[1]);        /* PID of target process */
+\&
+    newp = NULL;
+    if (argc == 4) {
+        new.rlim_cur = atoi(argv[2]);
+        new.rlim_max = atoi(argv[3]);
+        newp = &new;
+    }
+\&
+    /* Set CPU time limit of target process; retrieve and display
+       previous limit */
+\&
+    if (prlimit(pid, RLIMIT_CPU, newp, &old) == \-1)
+        err(EXIT_FAILURE, "prlimit\-1");
+    printf("Previous limits: soft=%jd; hard=%jd\en",
+           (intmax_t) old.rlim_cur, (intmax_t) old.rlim_max);
+\&
+    /* Retrieve and display new CPU time limit */
+\&
+    if (prlimit(pid, RLIMIT_CPU, NULL, &old) == \-1)
+        err(EXIT_FAILURE, "prlimit\-2");
+    printf("New limits: soft=%jd; hard=%jd\en",
+           (intmax_t) old.rlim_cur, (intmax_t) old.rlim_max);
+\&
+    exit(EXIT_SUCCESS);
+}
+.EE
+.\" SRC END
+.SH SEE ALSO
+.BR prlimit (1),
+.BR dup (2),
+.BR fcntl (2),
+.BR fork (2),
+.BR getrusage (2),
+.BR mlock (2),
+.BR mmap (2),
+.BR open (2),
+.BR quotactl (2),
+.BR sbrk (2),
+.BR shmctl (2),
+.BR malloc (3),
+.BR sigqueue (3),
+.BR ulimit (3),
+.BR core (5),
+.BR capabilities (7),
+.BR cgroups (7),
+.BR credentials (7),
+.BR signal (7)