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>
Michael Kerrisk