Vegard Nossum [Sat, 8 Feb 2020 15:37:14 +0000 (16:37 +0100)]
malloc.3: realloc() return value
One might be tempted to think that realloc() always requests a new
allocation before moving the contents over (at least in the case
where the new size is bigger than the original). This is not the
case; for example, on my system the following program:
Admittedly, the POSIX specification for exit() also uses octal.
However, 0xFF immediately indicates the lowest 8 bits to me
whereas I had to think a bit about the octal mask.
Cowritten-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Fri, 7 Feb 2020 16:39:51 +0000 (17:39 +0100)]
open.2: In O_TMPFILE example, describe alternative linkat() call
This was already shown in an earlier version of the page,
but Adam Borowski's patch replaced it with an alternative.
Probably, it is better to show both possibilities.
Reported-by: "Joseph C. Sible" <josephcsible@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Adam Borowski [Fri, 8 Mar 2019 19:40:59 +0000 (20:40 +0100)]
console_codes.4: Document \e[90m to 97, 100 to 107
Supported since fadb4244085cd04fd9c8b3a4b3bc161f506431f3 (4.9),
100..107 are supposed to be bright but this does not yet work
(unmerged patches to do so exist).
Signed-off-by: Adam Borowski <kilobyte@angband.pl> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Adam Borowski [Fri, 8 Mar 2019 19:40:57 +0000 (20:40 +0100)]
console_codes.4: \e[21m is now underline
Since 65d9982d7e523a1a8e7c9af012da0d166f72fc56 (4.17), it follows
xterm rather than common sense and consistency, being the only
command 1..9 where N+20 doesn't undo what N did. As libvte
0.51.90 got changed the same way, this behaviour will probably
stay.
Signed-off-by: Adam Borowski <kilobyte@angband.pl> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Rich Felker [Wed, 5 Feb 2020 00:16:10 +0000 (01:16 +0100)]
cmsg.3: Clarify alignment issues and correct method of accessing CMSG_DATA()
From an email by Rich Felker:
It came to my attention while reviewing possible breakage with
move to 64-bit time_t that some applications are dereferencing
data in socket control messages (particularly SCM_TIMESTAMP*)
in-place as the message type, rather than memcpy'ing it to
appropriate storage. This necessarily does not work and is not
supportable if the message contains data with greater alignment
requirement than the header. In particular, on 32-bit archs,
cmsghdr has size 12 and alignment 4, but struct timeval and
timespec may have alignment requirement 8.
I found at least ptpd, socat, and ssmping doing this via Debian
Code Search:
and I suspect there are a good deal more out there. On most archs
they won't break, or will visibly break with SIGBUS, but in theory
it's possible that they silently read wrong data and this might
happen on some older and more tiny-embedded-oriented archs.
I think it's clear to someone who understands alignment and who's
thought about it that applications just can't do this, but it
doesn't seem to be documented, and an example in cmsg(3) even
shows access to int payload via *(int *)CMSG_DATA(cmsg) (of course
int is safe because its alignment is <= header alignment, but this
is not mentioned).
Could we add text, and perhaps change the example, to indicate
that in general memcpy needs to be used to copy the payload
to/from a suitable object?
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
perf_event_open.2: Mention EINTR for perf_event_open
Somewhat surprisingly, perf_event_open() can fail with EINTR when
trying to enable perf reporting for a uprobe that's already been
configured for use with ftrace. Mention this error in the man
page.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Mike Salvatore [Thu, 16 Jan 2020 21:15:09 +0000 (16:15 -0500)]
getcwd.3: wfix
This patch is a minor wording fix in getcwd.3 that changes "In the case getcwd()" to "In the case of getcwd()". This patch should apply cleanly to the master branch of the git repository.
Regards,
Mike Salvatore
From 3b68ad225dbaada2b1b55153dc57807b04531cd6 Mon Sep 17 00:00:00 2001
From: Mike Salvatore <mike.salvatore@canonical.com>
Date: Thu, 16 Jan 2020 16:08:08 -0500
Subject: [PATCH] getcwd.3: wfix
Signed-off-by: Mike Salvatore <mike.salvatore@canonical.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Adrian Reber [Tue, 17 Dec 2019 15:05:05 +0000 (16:05 +0100)]
clone.2: Add clone3() set_tid information
Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Adrian Reber <areber@redhat.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
John Hubbard [Thu, 19 Dec 2019 05:13:47 +0000 (21:13 -0800)]
move_pages.2: Remove ENOENT from the list of possible return values
Linux kernel commit e78bbfa82624 ("mm: stop returning -ENOENT from
sys_move_pages() if nothing got migrated") had the effect of
*never* returning -ENOENT, in any situation. So we need to update
the man page to reflect that ENOENT is not a possible return
value.
Acked-by: Michal Hocko <mhocko@suse.com> Cc: Brice Goglin <Brice.Goglin@inria.fr> Cc: Yang Shi <yang.shi@linux.alibaba.com> Cc: Christoph Lameter <cl@linux.com> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
the pointer 'buf' is cast to a more strictly aligned pointer type.
This is undefined behaviour. One possible solution to make sure
that buf is correctly aligned is to declare buf as an array of
struct nlmsghdr. Other solutions include allocating the array on
the heap, use an union, or stdalign features. With this patch,
the buffer still contains 8192 bytes.
This was raised on Stack Overflow:
https://stackoverflow.com/questions/57745580/netlink-receive-buffer-alignment
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Andy Lutomirski [Wed, 4 Dec 2019 20:30:45 +0000 (12:30 -0800)]
modify_ldt.2, set_thread_area.2: Fix type of base_addr
Historically (before Linux 2.6.23), base_addr was unsigned long
for 32-bit code and unsigned int for 64-bit code. In other words,
it was always a 32-bit value. When the ldt.h header files were
unified, the type became unsigned int on all systems. Update
modify_ldt.2 and set_thread_area.2 accordingly.
Indeed, on x86, the GDT and LDT specify 32-bit bases for code and
data segments, and this has nothing to do with the kernel.
Reported-by: "Metzger, Markus T" <markus.t.metzger@intel.com> Signed-off-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Yang Xu [Tue, 3 Dec 2019 06:05:53 +0000 (14:05 +0800)]
quotactl.2: Add EINVAL error of Q_XQUOTARM operation
Since kernel commit 3dd4d40b4208("xfs: Sanity check flags
of Q_XQUOTARM call"), it has added flags check. If it is
not usr,grp,prj quota type, it will report EINVAL.
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Adrian Reber [Thu, 28 Nov 2019 12:46:49 +0000 (13:46 +0100)]
clone.2: tfix
Added two missing parentheses
Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Adrian Reber <areber@redhat.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk [Thu, 21 Nov 2019 08:35:35 +0000 (09:35 +0100)]
clone.2: Note that CLONE_THREAD causes similar behavior to CLONE_PARENT
The introductory paragraphs note that "the calling process" is
normally synonymous with the "the parent process", except in the
case of CLONE_PARENT. The same is also true of CLONE_THREAD.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
projects / thirdparty / man-pages.git / log
