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>
Heinrich Schuchardt