Closing the fanotify FD was discussed in two places.
Merge them into one location, and discard redundant text.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>
Michael Kerrisk