The fanotify file descriptor will be implicitly closed by process
termination, and in any case it was not closed explicitly in all
process termination paths.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Stefan:
I'm playing with the PACKET_RX_RING option to packet sockets and I
noticed that the status field from the tpacket_hdr structures
inside the mmaped buffer is actually a bit mask. I'm testing with
4Gbps traffic rates and sometimes I get status=5. I'm using Ubuntu
12.04 with a 3.8.0-29 kernel, and at least from the code (I got it
using "sudo apt-get source linux-image-$(uname -r)") it seems the
5 means TP_STATUS_USER | TP_STATUS_LOSING. The 3.8.0 kernel code
has this line in tpacket_rcv():
/*
* LOSING will be reported till you read the stats,
* because it's COR - Clear On Read.
* Anyways, moving it for V1/V2 only as V3 doesn't need this
* at packet level.
*/
if (po->stats.tp_drops)
status |= TP_STATUS_LOSING;
Daniel:
Now to your question. It can easily be seen from the if_packet.h header
file http://lingrok.org/xref/linux-net-next/include/uapi/linux/if_packet.h#93
that TP_STATUS_* are individual bits that are set in tp_status field.
TP_STATUS_USER simply means a frame was received in the ring and is
ready for user space to be processed. If the field also indicates
TP_STATUS_LOSING then this means that there were packet drops in the
rx ring itself so a user knows it didn't get all traffic. This bit
is being reset on getsockopt() when querying PACKET_STATISTICS,
otherwise it stays. Drops occur when the ring buffer was not emptied
fast enough by user space (so no free slot with TP_STATUS_KERNEL), e.g.
due to high incoming traffic load. However, the current frame you're
reading that has TP_STATUS_USER|TP_STATUS_LOSING is fine by itself.
Acked-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Carsten Andrich <carsten.andrich@tu-ilmenau.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I stumbled upon an error in packet.7 regarding the meaning of the
PACKET_LOSS socket option. According to the current git version of
linux-man setting PACKET_LOSS causes malformed packets to *not* be
silently dropped.
However it is the other way round. If PACKET_LOSS is *not* set,
malformed packets will be marked TP_STATUS_WRONG_FORMAT and the
transmission process aborted, leaving untransmitted packets in
the ring. If it *is* set, malformed packets will be silently
skipped, their status set to TP_STATUS_AVAILABLE and the
transmission process continued with the following packet.
This behaviour can be clearly seen in net/packet/af_packet.c:
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/net/packet/af_packet.c#n2300
The value accompanying TP_PACKET_LOSS translates into po->tp_loss:
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/net/packet/af_packet.c#n3304
I inverted the meaning of PACKET_LOSS and clarified the
description in the attached patch.
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The sum at the beginning of line "intr" includes also
unnumbered interrupts.
(Change made in kernel commit
a2eddfa95919a730e0e5ed17e9c303fe5ba249cd)
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jan Moskyto Matejka <mq@suse.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The sentence in open(2) man page in notes for O_DIRECT flag:
"Under Linux 2.6, alignment to 512-byte boundaries suffices."
is not universally correct. The alignment is a property of the
storage, for example, 4k-sector drives with no 512 byte sector
emulation will be unable to perform 512-byte direct I/O.
The patch clarifies this sentence.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions pthread_attr_setstack() and pthread_attr_getstack()
are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions pthread_attr_setscope() and pthread_attr_getscope()
are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions pthread_attr_setschedpolicy() and
pthread_attr_getschedpolicy() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions pthread_attr_setschedparam() and
pthread_attr_getschedparam() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions pthread_attr_setinheritsched() and
pthread_attr_getinheritsched() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As noted by Heinrich:
The manpage of msync(2) says:
"msync() flushes changes made to the in-core copy of a file
that was mapped into memory using mmap(2) back to disk."
...
"back to disk" implies that the file system is forced to
actually write to the hard disk, somewhat equivalent to
invoking sync(1). Is that guaranteed for all file systems?
Not all file systems are necessarily disk based
(e.g. davfs, tmpfs).
So shouldn't we write:
"... back to the file system."
http://pubs.opengroup.org/onlinepubs/007904875/functions/msync.html
says "... to permanent storage locations, if any,"
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk