man/man2/getdents.2: Document system call interface of getdents64
The count argument of the getdents64 system call is assumed to not exceed
INT_MAX. The glibc function accepts a size_t and passes INT_MAX to the kernel
if count exceeds INT_MAX.
man/man7/hostname.7: A hostname may not end with a hyphen either
On 2026-04-06T19:19:36+0000, Neitzert, Greg A wrote:
> At the bottom of your man page you do refer in the SEE ALSO to the
> pertinent RFCs:
>
> IETF RFC 1123 ⟨http://www.ietf.org/rfc/rfc1123.txt⟩
> IETF RFC 1178 ⟨http://www.ietf.org/rfc/rfc1178.txt⟩
>
> RFC 1178 has some general best practices and is not really governing
> for this. RFC 1123 however, and the RFC it refers back to, RFC-952,
> are directly on point.
>
> RFC UPDATES RFC-952 and refers to it:
>
> "The syntax of a legal Internet host name was specified in RFC-952
> [DNS:4]. One aspect of host name syntax is hereby changed: the
> restriction on the first character is relaxed to allow either a
> letter or a digit. Host software MUST support this more liberal
> syntax.
>
> Host software MUST handle host names of up to 63 characters and
> SHOULD handle host names of up to 255 characters."
>
>
> Referring back to RFC-952:
>
> "1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
> to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
> sign (-), and period (.). Note that periods are only allowed when
> they serve to delimit components of "domain style names". (See
> RFC-921, "Domain Name System Implementation Schedule", for
> background). No blank or space characters are permitted as part of
> a name. No distinction is made between upper and lower case. The
> first character must be an alpha character. The last character
> must not be a minus sign or period."
>
>
> Taking RFC 952, and the updates in RFC-1123 we end up with the
> following:
> 1. Length is now of 63 characters minimum (superceding 24).
> 2. The first character must be an alpha (or numeric - as amended by
> RFC 1123).
> 3. The last character MUST NOT be a minus sign (from RFC 952 and left
> unchanged).
>
> Therefore, to be accurate with the standard you are referring to
> (RFC 1123 and the RFC it updates 952), I believe you should have:
>
> "A hostname may not start or end with a hyphen."
>
> All of your text is in harmony with RFC 952 and RFC 1123 except for
> the issue regarding the hyphens - at least from my reading.
Stan Ulbrych [Mon, 30 Mar 2026 20:50:55 +0000 (22:50 +0200)]
man/man3/strptime.3: tfix
A little patch to fix a few little issues I noticed in the doc. I've
never contributed here before so I'm not sure if I'm doing it all
right, if not, apologies!
In case of idmapped mounts and statmount(), three cases can occur:
1. The mount is not an idmapped mount. In this case, smbuf->mask will
*not* have STATMOUNT_MNT_{UID,GID}MAP set.
2. The mount is an idmapped mount but *all* its mappings are *not*
resolvable in the user namespace of the caller.
In this case, smbuf->mask will have STATMOUNT_MNT_{UID,GID}MAP set
but smbuf->mnt_{uid,gid}map_num will be 0.
3. The mount is an idmapped mount and *all* its mappings are resolvable
in the user namespace of the caller.
In this case, smbuf->mask will have STATMOUNT_MNT_{UID,GID}MAP set
and mbuf->mnt_{uid,gid}map_num will be greater than 0.
The current documentation fails to differentiate between case 1 and 2
and incorrectly states that STATMOUNT_MNT_{UID,GID}MAP will be set for
non-idmapped mounts.
We can verify that the above is the case by looking at [1] and is made
explicitly clear by the comment in the implementation [2]. The case for
STATMOUNT_MNT_{UID,GID}MAP not being raised for a non-idmapped mount can
be verified by running this program [3].
Ben Kallus [Wed, 18 Mar 2026 14:49:37 +0000 (10:49 -0400)]
man/man2/mmap.2: Document that MAP_GROWSDOWN doesn't affect mmap return value.
The man page states that the MAP_GROWSDOWN flag causes the kernel to
return an address one page lower than the mapping created. This is not
true; the kernel returns the base address of the mapping created, just
as it does when MAP_GROWSDOWN is not passed. This can be confirmed by
inspecting "/proc/self/maps" after making a gd mapping, and comparing it
to the returned value from mmap.
You can confirm this by running this example program:
Vivian Wang [Mon, 16 Mar 2026 14:07:52 +0000 (22:07 +0800)]
man/man5/proc_pid.5: Clarify which user namespace affects permissions
A more careful reading of fs/proc/base.c (since v4.11, as of v7.0-rc1)
reveals that it is not task->cred->user_ns that is checked, but
task->mm->user_ns, which is set during execve(2) (and copied over in
fork(2) and so on) [1], and is the correct user namespace to check for
ptrace-related purposes. Clarify the relevant text.
Fixes: ae636827 (2018-07-05; "proc.5: Fix description of /proc/PID/* ownership to account for user namespaces") Signed-off-by: Vivian Wang <dramforever@live.com>
Message-ID: <OSCPR01MB134682A1A80B8C9FB71CBA64DC640A@OSCPR01MB13468.jpnprd01.prod.outlook.com> Signed-off-by: Alejandro Colomar <alx@kernel.org>
Emanuele Rocca [Fri, 13 Mar 2026 19:15:54 +0000 (20:15 +0100)]
man/man5/core.5: Document the %f and %C core_pattern specifiers
Whilst going through the relevant kernel code in fs/coredump.c,
I noticed that two core pattern specifiers supported by Linux are
missing from man5/core.5. Document them now.
Document STATMOUNT_SUPPORTED_MASK flag and the corresponding field
introduced by it. It is used to determine the flags supported by the
current kernel. The text is based on this commit message [1].
Document the STATMOUNT_{UIDMAP,GIDMAP} flags and the corresponding
fields introduced by them. Most of this is based on the commit message
provided here [1].
CONTRIBUTING.d/git: core.abbrev: Use only 8 characters
8 characters is enough for showing most commits unambiguously.
12 would be necessary if we didn't have the date. However, the date can
be used to disambiguate a commit better than a longer hash. Let's cut
some characters to make commit references more readable.
Fixes: a8aa0eaf (2026-02-08; "CONTRIBUTING.d/: Document format of 'Fixes:' trailer fields") Fixes: e9fa66a0 (2026-02-08; "CONTRIBUTING.d/git: core.abbrev: Set to 12") Signed-off-by: Alejandro Colomar <alx@kernel.org>
Seth McDonald [Mon, 16 Feb 2026 11:45:30 +0000 (21:45 +1000)]
man/man2/mincore.2: HISTORY: Update appearances of mincore(2)
mincore(2) was implemented in FreeBSD on 1995-10-21,[1] and was first
included in the FreeBSD 2.2 release on 1997-03.[2]
It was implemented in NetBSD on 1999-06-15,[3] and was first included in
the NetBSD 1.5 release on 2000-12-06,[4] (despite the commit message
stating its intended inclusion in NetBSD 1.4.1).
It was implemented in OpenBSD on 2001-03-09,[5] and was first included
in the OpenBSD 2.9 release on 2001-06-01.[6]
All other listed systems are taken at face value and rearranged in
chronological-ish order.
[1] Dyson, John (21 Oct 1995). "Implement mincore system call."
FreeBSD source tree (Git repository). Commit 02c04a2f6c83ee28ed637d120296d04da8f03372.
[2] The FreeBSD Project (29 Nov 2025). "Prior Releases – EOL".
<https://www.freebsd.org/releases>
[3] Thorpe, Jason (15 Jun 1999). "Several changes, developed and tested
concurrently:". NetBSD src (CVS repository).
<https://cvsweb.netbsd.org/bsdweb.cgi/src/sys/uvm/uvm_mmap.c?rev=1.22>
[4] The NetBSD Foundation (2026). "History of NetBSD releases".
<https://www.netbsd.org/releases/formal.html>
[5] art (9 Mar 2001). "More syncing to NetBSD." OpenBSD src (CVS
repository).
<https://cvsweb.openbsd.org/src/sys/uvm/uvm_mmap.c?rev=1.7&content-type=text/x-cvsweb-markup>
[6] de Raadt, Theo (1 Jun 2001). "OpenBSD 2.9".
<https://www.openbsd.org/29.html>
man/man2/: HISTORY, STANDARDS: Update history of syscalls H-M
On 2026-01-26T12:28:10+0000, Seth McDonald wrote:
> This set updates the history of system calls H to M.
>
> While I have been thorough with my research, I would encourage those
> interested to double-check that my edits make sense given the listed
> sources. Particularly for linkat(2), SEEK_DATA/SEEK_HOLE, mkdirat(2),
> and mincore(2), since they took significantly more time and research
> than other functions.
Seth McDonald [Mon, 26 Jan 2026 12:30:21 +0000 (12:30 +0000)]
man/man2/msgop.2: STANDARDS, HISTORY: Update POSIX appearances of msg{rcv,snd}(2)
msgrcv(2) and msgsnd(2) appeared in SUSv1.[1] The functions were added
to POSIX.1-2001 when POSIX and SUS merged, but as an XSI extension
(still SUS-only).[2][3] And they remain as an XSI extension in
POSIX.1-2024.[4][5]
[1] X/Open CAE Specification, System Interfaces and Headers Issue 4,
Version 2, Chapter 3 "System Interfaces", pp. 408-411.
[2] IEEE Std 1003.1-2001, Volume 2, Chapter 3 "System Interfaces", pp.
806-808.
<https://pubs.opengroup.org/onlinepubs/009604499/functions/msgrcv.html>
[3] IEEE Std 1003.1-2001, Volume 2, Chapter 3 "System Interfaces", pp.
809-811.
<https://pubs.opengroup.org/onlinepubs/009604499/functions/msgsnd.html>
[4] IEEE Std 1003.1-2024, Volume 2, Chapter 3 "System Interfaces", pp.
1475-1477.
<https://pubs.opengroup.org/onlinepubs/9799919799/functions/msgrcv.html>
[5] IEEE Std 1003.1-2024, Volume 2, Chapter 3 "System Interfaces", pp.
1478-1480.
<https://pubs.opengroup.org/onlinepubs/9799919799/functions/msgsnd.html>
Seth McDonald [Mon, 26 Jan 2026 12:30:16 +0000 (12:30 +0000)]
man/man2/msgget.2: STANDARDS, HISTORY: Update POSIX appearances of msgget(2)
msgget(2) appeared in SUSv1.[1] The function was added to POSIX.1-2001
when POSIX and SUS merged, but as an XSI extension (still SUS-only).[2]
And it remains an XSI extension in POSIX.1-2024.[3]
[1] X/Open CAE Specification, System Interfaces and Headers Issue 4,
Version 2, Chapter 3 "System Interfaces", pp. 406-407.
[2] IEEE Std 1003.1-2001, Volume 2, Chapter 3 "System Interfaces", pp.
804-805.
<https://pubs.opengroup.org/onlinepubs/009604499/functions/msgget.html>
[3] IEEE Std 1003.1-2024, Volume 2, Chapter 3 "System Interfaces", pp.
1473-1474.
<https://pubs.opengroup.org/onlinepubs/9799919799/functions/msgget.html>
Seth McDonald [Mon, 26 Jan 2026 12:30:11 +0000 (12:30 +0000)]
man/man2/msgctl.2: STANDARDS, HISTORY: Update POSIX appearances of msgctl(2)
msgctl(2) appeared in SUSv1.[1] The function was added to POSIX.1-2001
when POSIX and SUS merged, but as an XSI extension (still SUS-only).[2]
And it remains an XSI extension in POSIX.1-2024.[3]
[1] X/Open CAE Specification, System Interfaces and Headers Issue 4,
Version 2, Chapter 3 "System Interfaces", pp. 404-405.
[2] IEEE Std 1003.1-2001, Volume 2, Chapter 3 "System Interfaces", pp.
802-803.
<https://pubs.opengroup.org/onlinepubs/009604499/functions/msgctl.html>
[3] IEEE Std 1003.1-2024, Volume 2, Chapter 3 "System Interfaces", pp.
1471-1472.
<https://pubs.opengroup.org/onlinepubs/9799919799/functions/msgctl.html>
Seth McDonald [Mon, 26 Jan 2026 12:29:51 +0000 (12:29 +0000)]
man/man2/mlock.2: HISTORY: Update POSIX appearances of m(un)lock(all)(2)
mlock(2), munlock(2), mlockall(2), and munlockall(2) appeared in
POSIX.1-1996.[1][2]
[1] ISO/IEC 9945-1:1996, Section 12.1.1 "Lock/Unlock the Address Space
of a Process".
[2] ISO/IEC 9945-1:1996, Section 12.1.2 "Lock/Unlock a Range of Process
Address Space".
projects / thirdparty / man-pages.git / log
