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