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 function wcwidth() is thread safe with exceptions.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The function wctype() is thread safe with exceptions.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The function wctrans() is thread safe with exceptions.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
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 functions futimes() and lutimes() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions erfc(), erfcf() and erfcl() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions erf(), erff() and erfl() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions expm1(), expm1f() and expm1l() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions cos(), cosf() and cosl() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions asinh(), asinhf() and asinhl() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions copysign(), copysignf() and copysignl() are thread
safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions atoi(), atol() and atoll() are thread safe with
exceptions.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
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>
The function atof() is thread safe with exceptions.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The functions atan(), atanf() and atanl() are thread safe.
Signed-off-by: Peng Haitao <penght@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It's not true that the return value is suitably aligned for "any
variable"; for example, it's unsuitable for a variable like
float *x __attribute__ ((__vector_size__ (32)));
which requires 32-byte alignment. Types like this are defined in
<avxintrin.h>, and with 16-byte alignment in <emmintrin.h> and
<xmmintrin.h>, so the application programmer need not even know
that a vector_size attribute has been applied.
On an x86 architecture, a program that loads from or stores to a
pointer with this type derived from malloc can crash because GCC
generates an aligned load/store, like MOVDQA.
The C99 standard (TC3, as of N1256) does say the return value is
suitably aligned for "any type of object". The C11 standard (as
of N1570) revises this to any type with "fundamental alignment",
which means an alignment "supported by the implementation in all
contexts", which I suppose tautologically includes aligning
malloc/realloc return values.
The actual behavior of current glibc malloc is to align to the
greater of 2 * sizeof(size_t) and __alignof__ (long double),
which may be one bit greater than this commit promises.
Signed-off-by: Greg Price <price@mit.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>
Michael Kerrisk