As noted by Carlos, there's quite a bit of inconsistency across
pages. Use 'addr' and 'addrlen' consistently in variables and
function arguments.
Cowritten-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
When aio_sigevent.sigev_notify is set to SIGEV_SIGNAL, signal
handlers called for asynchronous I/O operations will have
si->si_code set to SI_ASYNCIO. Check to make sure that
si->si_value.sival_ptr is defined.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A complete example demonstrating the usage of sockets for local
interprocess communication is added.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>
[Part of a general change to remove cruft from this page.]
Much of the detail on hardware specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.)
Here, we remove some ancient x86 options.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The information here relates to ancient systems
Some (possibly more up to date) info can be found
in Documentation/kernel-parameters.txt.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
In the specific case of floppy drives: the drivers still
exist, but it's been a while since most of saw these devices
in the wild. So, just refer the reader to the kernel source
file for details. (The detail in this man page was after all
originally drawn from that file.)
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
See kernel commit a88dc06cd515b3bb9dfa18606e88d0be9a5b6ddd
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
[Part of a general change to remove cruft from this page.]
Much of the detail on device-driver specifics in this page dates
from the 20th century. (The last major update to this page was in
man-pages-1.14!) It's hugely out of date now (many of these
devices disappeared from the kernel years ago.) Arguably, this
kind of detail should never have been placed in a man page to
begin with, since devices come and go. Remove such text, and
where appropriate and possible add pointers to files in the
kernel Documentation/ directory.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
"xattr" is a more meaningful name than "attr" (it resonates
with the names of the system calls), so as long as we are
moving the page to a new section, we'll change the name as well,
and retain an acl(5) link so that old references remain valid.
Reported-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
From experimentation, I found a 16kB limit on name + value +
overhead bytes. Digger deeper, I see that
https://btrfs.wiki.kernel.org/index.php/Project_ideas#Unlimited_extended_attributes
says:
Unlimited extended attributes
Not claimed — no patches yet — Not in kernel yet
Currently size of value of an extended attribute must fit into
inline space (~3900 on 4k leaf size), while other filesystems
do not limit the size. Add a new b-tree item to hold the xattr
value in extents.
And reading mkfs.btrfs(8) reveals that the default node (AKA leaf)
size is 16kB.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After discussions with Andreas Gruenbacher, it makes sense to
move this page into man-pages, since it mostly relates to
kernel details.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This was fixed in glibc 2.1.1, which is a long while ago.
And in any case, there is nothing special about this case;
it's just one of those times when glibc lags.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The existing text makes no sense. The check is based
purely on a capability check. (Kernel function
net/packet/af_packet.c::packet_create()
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It's important that the reader receive contemporary information.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
While a lot of the changes are issues of presentation,
there are also issues of grammar and punctuation.
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Looking over the man page for 'tcp' I came across a reference to
tuning the 'TCP_SYNQ_HSIZE' parameter when increasing
'tcp_max_syn_backlog' above 1024. However, this static sizing was
removed back in Linux 2.6.20 in favor of dynamic scaling - as
part of commit 72a3effaf633bcae9034b7e176bdbd78d64a71db.
I have included a patch below with reference to this commit, and
that the process detailed is not required on >= Linux 2.6.20.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>