The original list of registers was created by confusing strace
source code--this is for parsing legacy 32-bit code (which is
dead and no one cares). Update the list to reflect native ia64
syscall interface.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The manpage did not mention RB_POWER_OFF which is the glibc
symbolic name for LINUX_REBOOT_CMD_POWER_OFF.
$ cd /usr/include
$ cat x86_64-linux-gnu/sys/reboot.h | grep POWER_OFF
define RB_POWER_OFF 0x4321fedc
Signed-off-by: Elie De Brauwer <eliedebrauwer@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Clarify the perf_event_open behavior with respect to the disabled
bit and creating event groups.
Reported-by: Sudhanshu Goswami <Sudhanshu.Goswami@emc.com>
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Warn that using the perf_event_open "exclusive" bit, while it might seem
like a good idea, might lead to all 0 results in some common usage cases.
Reported-by: Sudhanshu Goswami <Sudhanshu.Goswami@emc.com>
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Here's an updated version of [David Ahern's] patch that
expands the "mmap" definition as well as that of "mmap_data".
Also some manpage related formatting improvements from the
original patch.
Link: https://lkml.org/lkml/2013/11/11/505
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Acked-by: David Ahern <dsahern@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This patch attempts to clarify the pid and cpu options to
perf_event_open().
It does two things:
1. Tries to make clear that the "pid" argument can mean
process *or* thread. This is made confusing by
how Linux uses the terms mostly interchangeably.
2. The cpu/pid documentation was confusing because of
how the parameters are interdependent. Since there
are only 6 possible combinations I broke out the
possibilities into a table.
Reported-by: Manuel Selva <selva.manuel@gmail.com>
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
events==0 does not mean that revents is always returned as
zero. The "output only" events (POLLHUP, POLLERR, POLLNVAL)
can still be returned.
See https://bugzilla.kernel.org/show_bug.cgi?id=61911
Reported-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
See https://bugzilla.kernel.org/show_bug.cgi?id=42705
Reported-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reported-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It turns out that the perf_event mmap page rdpmc/time setting was
broken, dating back to the introduction of the feature. Due
to a mistake with a bitfield, two different values mapped to
the same feature bit.
A new somewhat backwards compatible interface was introduced
in Linux 3.12. A much longer report on the issue can be found
here:
https://lwn.net/Articles/567894/
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A new perf_event related ioctl, PERF_EVENT_IOC_ID, was added
in Linux 3.12.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A new PERF_SAMPLE_IDENTIFIER sample type was added in Linux 3.12.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Support for the PERF_COUNT_SW_DUMMY event type was added in
Linux 3.12.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
fallocate() zeroes only space that did not previously contain
data, but leaves existing data untouched.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The PERF_EVENT_IOC_PERIOD ioctl was broken until 2.6.36,
and it turns out that the ARM architecture has some
differing behavior too.
Reported-by: Andreas Sandberg <andreas.sandberg@it.uu.se>
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The following documents the E2BIG error return for
perf_event_open().
I actually ran into this error the hard way and it took me
half a day to figure out why my ->size value was changing.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
When I asked to webmaster@kernel.org, Konstantin Ryabitsev
answered that the ".nl." is "an obsolete scheme and really
should be changed to just ftp.kernel.org".
Signed-off-by: Rodrigo Campos <rodrigo@sdfg.com.ar>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The existing text describes the timestamp fields as 'time_t'
and delegates discussion of nanosecond timestamps under NOTES.
Nanosecond timestamps have been around for a while now,
and are in POSIX.1-2008, so reverse the orientation of the
discussion, putting the nanosecond fields into DESCRIPTION
and detailing the historical situation under NOTES.
Reported-by: Yang Yang <yangyang.gnu@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This started out as just adding the new perf_event_open features
from Linux 3.11 (which was the addition of transactional memory
defines for PERF_SAMPLE_BRANCH_STACK samples) but turned into a
general cleanup of the PERF_SAMPLE_BRANCH_STACK documentation.
The main clarification is that at least one of the non-privilege values
must be set or else perf_event_open will return an EINVAL error.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Note that NFS versions since version 3 support an "access" call
so that the client doesn't have to guess permissions or ID
mapping on its own.
(See RFC 1813 sections 1.7 and 3.3.4.)
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The attached patch adds four ioctls from linux/msdos_fs.h to the
ioctl_list(2) manpage.
The ioctl FAT_IOCTL_GET_ATTRIBUTES reads FAT attributes of a
file a mounted vfat file system. I tested this on Linux
2.6.33, an example script can be found at
http://www.perlmonks.com/?node_id=832623
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
EINVAL can be returned by open(2) when the underlying filesystem
doesn't support O_DIRECT. It is documented in the NOTES section
but this patch adds it to the list of possible errors.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
More clearly describe the weirdness in the return value of this
system call, and ote the problems it creates in in BUGS
Reported-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
More clearly describe the weirdness in the return value of this
system call, and ote the problems it creates in in BUGS
Reported-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Notwithstanding 24d01c530c,
"filesystem" is the form used by the great majority of man pages
outside the man-pages project and in a number of other sources,
so let's go with that.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The indentation of the MMAP layout section wasn't quite right.
I think this improves things but I admit I'm not an expert at the
low-level indentation directives.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
O_DIRECTORY can also be used with, for example, O_PATH.
Reorted-by: Geoffrey Thomas <gthomas@mokafive.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I noticed that the example in the readlink.2 man pages does error
checking for a race condition that would cause the value of the
symbolic link to get larger. However, it doesn't handle the
opposite case, in which the value gets shorter. (The NULL
terminator is always set at the old, longer offset.) This could
cause the program to operate on uninitialized data.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This improves the documentation of the various
perf_event_open()-related sysfs files.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It turns out PERF_IOC_FLAG_GROUP was broken from 75f937f24bd9
(in Linux 2.6.31, the initial perf_event release) until
724b6daa1 (Linux 3.4).
I've done some extensive kernel source code digging plus
running tests of various kernels and I hope the info
presented is accurate now.
(Patch edited somewhat by mtk.)
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
For every PTRACE_O_TRACEfoo option, mention that old-style SIGSTOP
is replaced by PTRACE_EVENT_STOP if PTRACE_SEIZE attach was used.
Mention the same thing again in the description of
PTRACE_EVENT_STOP.
Acked-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This patch updates the perf_event_open() documentation to include
new interfaces added in the 3.10 kernel.
It also documents a few [To be documented] instances left over
from the 3.7 kernel.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The perf_event_open() ENABLE/DISABLE/RESET ioctls can take an
argument, PERF_IOC_FLAG_GROUP. This wasn't documented at all
until about a year ago (despite the support being there from
the beginning) so I missed this when initially writing
the man page.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
During the review of static analysis results, we discovered a
functional, but non-portable, use of execve(). For example:
char *cmd[] = { "/path/to/some/file", NULL };
execve(cmd[0], cmd, NULL);
The call succeeds. Yet, the static analysis tool (rightly)
pointed out that envp could be dereferenced. But digging into
glibc and the kernel, it appears that like argv, envp when NULL
is treated as if it were an empty list.
So, to clear things up, I'm submitting this patch to update the
man page to indicate that envp is treated like argv.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Clarify the perf_event_open() wakeup_events/wakeup_watermark
fields a bit, based on info from kernel commit cfeb1d90a1b1.
Signed-off-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
pthread_setname_np() and pthread_getname_np() and
/proc/self/task/TID/comm provide access to the same
attribute.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Currently the io_setup.2 man page describes what the kernel really
does, i.e., that the resulting context may be able to hold more
than the 'nr_event's operations because the memory allocated in
kernel is rounded to be multiple of page size.
It is better not to expose this implementation detail and
simply state that the resulting context is suitable for
'nr_events' operations.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
Acked-by: Jeff Moyer <jmoyer@redhat.com>
The description of ia64 clone2() should follow the discussion
of the raw system call interface.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
And further clarify the distinction between the system call
and the wrapper function in the introductory text.
Reported-by: Peter Schiffer <pschiffe@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The description was rather vague, citing a "list of I/O contexts"
and stating that it "can" cancel outstanding requests. This
update makes things more concrete so that the reader knows exactly
what's going on.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
nr_events is technically the number of completion events that can
be stored in the completion ring. The wording of the man page:
"capable of receiving at least nr_events" seems dubious to me,
only because I worry that folks might interpret that to mean
'nr_events' total, instead of 'nr_events' concurrently.
Further, I've added information on where to find the per-user
limit on 'nr_events', /proc/sys/fs/aio-max-nr. Let me know if
you think that is not relevant.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I looked back through the kernel code, and the timeout was
never updated in any case. I've submitted a patch upstream
to change the comment above io_getevents.
Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk