public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: Eugene Syromyatnikov <evgsyr@gmail.com>
To: linux-man@vger.kernel.org
Cc: Alejandro Colomar <alx.manpages@gmail.com>
Subject: [PATCH v4] getrlimit.2: old_getrlimit/ugetrlimit and RLIM_INFINITY discrepancies
Date: Fri, 30 Jul 2021 02:15:23 +0200	[thread overview]
Message-ID: <20210730001523.GA5767@asgard.redhat.com> (raw)

Historically, Linux didn't follow SUS with respect to RLIM_INFINITY
signedness; it was changed during 2.4 development cycle, but in somewhat
peculiar and arch-dependent fashion due to backward compatibility
concerns.

Signed-off-by: Eugene Syromyatnikov <evgsyr@gmail.com>
---
 man2/getrlimit.2 | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/man2/getrlimit.2 b/man2/getrlimit.2
index 648fd3c..df392a5 100644
--- a/man2/getrlimit.2
+++ b/man2/getrlimit.2
@@ -646,6 +646,40 @@ The name of the glibc wrapper function is
 .BR prlimit ();
 the underlying system call is
 .BR prlimit64 ().
+The corresponding infinity value constant is provided in
+.I <linux/resource.h>
+as
+.BR RLIM64_INFINITY.
+.PP
+Linux 2.2 and earlier versions used signed types for limits;
+that was changed
+(along with the value of
+.BR RLIM_INFINITY )
+.\" http://repo.or.cz/davej-history.git/blobdiff/129f8758d8c41e0378ace0b6e2f56bbb8a1ec694..15305d2e69c3a838bacd78962c07077d2821f255:/include/linux/resource.h
+during the 2.4 development cycle,
+as it was not compatible with the Single UNIX Specification.
+However, in order to preserve backward compatibility,
+the routine
+.IR sys_old_getrlimit
+was implemented for the
+.B __NR_getrlimit
+syscall slot,
+with infinity checks being performed against a literal 0x7fffffff value,
+and
+.I sys_getrlimit
+has been exposed under a new name,
+.BR ugetrlimit ().
+Most newer architectures do not have the latter, with
+.BR getrlimit ()
+providing the conforming implementation.
+However, several architectures decided not to change the
+.B RLIM_INFINITY
+value: 32-bit MIPS and SPARC
+(but not 64-bit variants, that switched to the new value of (~0UL))
+retained the old 0x7fffffff value,
+and Alpha retained 0x7ffffffffffffffful.
+.\" ...along with a request to call when one runs into it:
+.\" https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/alpha/include/uapi/asm/resource.h#n15
 .SH BUGS
 In older Linux kernels, the
 .B SIGXCPU
-- 
2.1.4


                 reply	other threads:[~2021-07-30  0:15 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210730001523.GA5767@asgard.redhat.com \
    --to=evgsyr@gmail.com \
    --cc=alx.manpages@gmail.com \
    --cc=linux-man@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox