It certainly seems like that change happened some time ago.
Reported-by: Marko Myllynen <myllynen@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Helpful for three purposes, 1) shows the expected naming scheme,
2) shows where to point LOCPATH to, and 3) gives an idea to the
attentive how to use a more generic, location independent
directory with location dependent, more specific ones.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
mmap() and msync() were already described as not leading to
inotify events. This patch adds munmap(). I created and executed
a test to verify this.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This example of the usage of the inotify API shows the
usage of inotify_init1(2) and inotify_add_watch(2) as well
as polling and reading from the inotify file descriptor.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Example from https://sourceware.org/glibc/wiki/Locales
After modifying a locale, make sure it compiles, and install it to a
temporary directory for testing:
unset LC_ALL
LOCALE=fi_FI
export I18NPATH=$HOME/locale-test/
export LOCPATH=$HOME/locale-test/
mkdir -p $LOCPATH
localedef --no-archive -f localedata/charmaps/UTF-8 -i localedata/locales/$LOCALE $I18NPATH/$LOCALE.UTF-8
LC_TIME=$LOCALE.UTF-8 locale -ck LC_TIME
LC_TIME=$LOCALE.UTF-8 locale -ck date_fmt
LC_TIME=$LOCALE.UTF-8 date
LC_CTYPE=$LOCALE.UTF-8 iconv -f UTF-8 -t ASCII//TRANSLIT < translit-test-input.txt
LC_COLLATE=$LOCALE.UTF-8 sort < sorting-test-input.txt
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk pointed me to alignment issues which may
arise when reading misaligned integers.
On some systems integer values can only be read if they are
correctly aligned. Other system have a lower performance when
reading from or writing to misaligned memory positions.
Therefore, the buffer used to call read(2) for a fanotify
file descriptor should have the same alignment as
struct fanotify_event_metadata.
Due to the casting to char* inside the macros
FAN_EVENT_OK and FAN_EVENT_NEXT we can use any
data structure for the buffer.
With the patch an array of struct fanotify_event_metadata is
used as buffer which seems a natural choice to ensure proper
alignment.
It should be remembered that the offset between events is given
by field event_len and iterating over the array may not be
allowable in future. Instead the macros should be used.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
FAN_EVENT_NEXT() does not update 'meta'; rather, it returns a
pointer to the next metadata structure. In addition, generally
rework the description to be a bit clearer and more detailed.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Change consistent with the fact that the scheduling overview
page is now sched(7) not sched_setscheduler(2).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
SCHED_DEADLINE content has been reviewed by Peter and Juri
Reviewed-by: Juri Lelli <juri.lelli@gmail.com>
Reviewed-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In a couple of places, sched_setscheduler(2) is mentioned as the
way of setting policies. But now there is sched_setattr(2) as
well, rewrite the text in a more generic way.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
There are nowadays multiple ways to set sched_priority (and
in fact there always were, since we also had sched_setparam(2)).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
All of the removed text is in sched_setscheduler(2) and
should have been trimmed from this page.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Different system calls use different 'errno' values to diagnose
exhaustion of the ephemeral port range.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Note the use of fanotify_mark() 'event_f_flags' to control
the file status flags for the file descriptors returned via
'fanotify_event_metadata.fd'.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
* Using large buffer sizes for read(2) is orthogonal to the
discussion of variable-length event structures.
* Move the discussion of the read() return value to follow
discussion of what the read() actually returns in its buffer.
* Related rewordings.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Update as per http://www.spinics.net/lists/linux-man/msg05624.html
where Jan Kara proposed to clarify the deletion of events from the
fanotify queue and the occurrence of ENOENT when writing to the
fanotify file descriptor.
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Most of this content derives from sched_setscheduler(2). In
preparation for adding a sched_setattr(2) page, it makes
sense to isolate out this general content to a separate
page that is referred to by the other scheduling pages.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A bug mentioned in fanotify_mark(2) need not be repeated in
fanotify(7) again.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
poll() and ppoll() are not among the primary calls in the API
(and anyway, select(), pselect(), and epoll were not mentioned).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
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>