The sentence is true for all man-pages. Remove it.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The abbreviation NPTL cannot be assumed to be common knowledge
of all readers of futex.7.
pthread.7 has details about the NPTL pthreads implementation.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
futex.7 is meant as overview of the usage of futexes. It should
point to the related man-pages.
pthreads are the main usage of futexes, refer to pthread.7.
Implementation of robust futexes requires knowledge of set_robust_list.2
and get_robust_list.2.
It is noworthy that a closing thread can wake up a futex. Hence mention
clone.2 and set_tid_address.2.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
s/la_pltenter()/la_pltexit()/
la_pltenter() is called regardless of the value of
framesizep but la_pltexit() is called only if la_pltenter()
returns with non-zero framesizep set. I spent long time to
figure out why la_pltexit() is not called at all.
Quoting comments in glibc/sysdeps/x86_64/dl-trampoline.h:
/* There's nothing in the frame size, so there
will be no call to the _dl_call_pltexit. */
and
/* At this point we need to prepare new stack for the function
which has to be called. We copy the original stack to a
temporary buffer of the size specified by the 'framesize'
returned from _dl_profile_fixup */
I think it's because it needs to preserve 'inregs' to be passed to
la_pltexit().
The _dl_profile_fixup() sets the '*framesizep' to maximum value of
what la_pltenter() sets. Please see glibc/elf/dl-runtime.c file.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Improve description of tcp_ecn, fix the RFC number and it's
not a boolean anymore since long time, and add a description
for tcp_ecn_fallback.
See also kernel doc under Documentation/networking/ip-sysctl.txt
on tcp_ecn and tcp_ecn_fallback.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
If files or directories are moved to other mounts, the inode is
deleted. Fanotify marks are lost.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Quoting Nicholas Miell:
PTHREAD_PROCESS_SHARED says any thread with access to the
memory containing the mutex can operate on the mutex and
POSIX basically ignores the idea that different processes
could be running completely incompatible executables or
whatever.
pthread_mutex_t has a bunch of #ifdefs in the middle of it
that change the structure size and layout between i386 and
x86_64.
Most importantly, the positions of the __nusers and __kind
fields are swapped (this looks to be an oversight dating
back to 2003 when __nusers was first introduced and carefully
preserved when the separate i386 and x86_64 versions of
pthreadtypes.h were merged into the single x86 version),
which means that when the lock and unlock functions attempt
to figure out what kind of mutex it is
(recursive/adaptive/whatever), they'll look at the wrong
field if the mutex is from the wrong architecture and then
things will break.
And then there's the fact that the rest of the struct is a
union in the 32-bit version and flat in the 64-bit version,
but that could have been worked around if you put a flag in
the __kind field that tells the 64-bit pthread library that
it is looking at a 32-bit mutex.
Reported-by: Nicholas Miell <nmiell@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The 32-bit ARM architecture in Linux has gained a vDSO as of the
4.1 release. (I was the primary author.)
Document the symbols exported by the ARM VDSO.
Accepted kernel submission:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332573.html
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In the example code you used %x rather than %p in the example
code for an audit library. The problem is that it truncates the
pointers on 64b platforms. So you get something like:
la_symbind64(): symname = strrchr sym->st_value = 0x7f4b8a3f8960
ndx = 222 flags = 0x0 refcook = 8b53e5c8 defcook = 8b537e30
rather than:
la_symbind64(): symname = fclose sym->st_value = 0x7fa452dd49b0
ndx = 1135 flags = 0x0 refcook = 0x7fa453f395c8 defcook = 0x7fa453f32e30
This has bitten me a handful of times when playing around with
audit test libraries to investigate its behavior.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The "ABI" doesn't really convey anything significant in
the title. These subsections are about describing differences
between the kernel and (g)libc interfaces.
Reported-by: Andries E. Brouwer <Andries.Brouwer@cwi.nl>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A PTY is not like a pipe - there may be delayed between data
being written at one end and it being available at the other.
This became particularly apparent after
commit f95499c3030f
("n_tty: Don't wait for buffer work in read() loop")
in Linux 3.12
See also the mail thread at https://lkml.org/lkml/2015/5/1/35
Date Mon, 04 May 2015 12:32:04 -0400
From Peter Hurley <>
Subject Re: [PATCH bisected regression] input_available_p()
sometimes says 'no' when it should say 'yes'
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Long ago, some page reworking moved this text to a somewhat
random location in the middle of the socket options list.
Move it to a sensible location, and at the same time,
rework the text to be a little clearer.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The manpage packet(7) currently states that:
"When you send packets it is enough to specify sll_family, sll_addr,
sll_halen, sll_ifindex."
This is incorrect: you also need to specify sll_protocol.
(The protocol specified when the socket is created is used for
filtering inbound packets, but not for constructing outbound
packets.)
I encountered this while researching a page for my website:
http://www.microhowto.info/howto/send_an_arbitrary_ethernet_frame_using_an_af_packet_socket_in_c.html
To empirically verify the behaviour I took my test code from the
above page then changed it to use different values for the third
argument to socket() and the sll_protocol field:
- socket created with ETH_P_ARP, packet sent with ETH_P_ARP:
packet sent with EtherType of ETH_P_ARP
- socket created with ETH_P_ARP, sll_protocol==0:
packet sent with EtherType of 0
- socket created with 0x88b5, sll_protocol==htons(ETH_P_ARP):
packet sent with EtherType of ETH_P_ARP
- socket created with ETH_P_ARP, sll_protocol==htons(0x88b5):
packet sent with EtherType of 0x88b5
This shows that leaving sll_protocol set to zero does not have
the desired effect and that it needs to be set to the desired
link-layer protocol.
There is code in the relevant kernel source file
(net/packet/af_packet.c) which appears to inspect the value of the
sll_protocol field and use it as the link-layer protocol number,
however I am not sufficiently familiar with this subsystem to be
fully confident of what is happening. The line in question is:
proto = saddr->sll_protocol;
In version 3.4 of the kernel this can be found in the functions
packet_snd and tpacket_snd. In version 2.6.26 it is in packet_sendmsg.
Below is a patch that adds sll_protocol to the list of required fields.
This may not be the whole truth, since it is not clear what role if any
sll_protocol, sll_halen or sll_addr would play when the socket type is
SOCK_RAW, however I'm confident it is more accurate than the page as it
stands at present.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This kernel constant is not exposed to user space.
Reported-by: Christophe Lohr <Christophe.Lohr@telecom-bretagne.eu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk