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>
I don't think rendering the dashes in the regex expression as the
en style makes sense. This is a literal regex, so use literal
dashes.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Carsten Andrich