Sort the options so that those defined in POSIX are listed first,
then followed by those defined in ISO/IEC TR 14652 in the order
of common convention in many widely used glibc locales.
Actual descriptions are unchanged.
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The timezone of LC_TIME is not in POSIX, only 6 (out of ~300)
glibc locales define it, the glibc code comment below from
glibc.git/programs/ld-time.c seems to suggest it's not a good
idea, and there's been a proposal in upstream [1] to remove the
existing timezone definitions from glibc locales so I think
it's actually better to leave this one undocumented:
/* XXX We don't perform any tests on the timezone value since this is
simply useless, stupid $&$!@... */
1) https://sourceware.org/ml/libc-alpha/2015-06/msg00098.html
Move the remaining LC_COLLATE FIXMEs together while at it.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The relationship between the locale time format syntax
and strftime() cannot be considered as obvious.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It's probably a good idea to refer to locale(7) so that a reader
can check what a category is about before describing them in
detail.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Many years ago, text was added to the page saying that it is
implementation-dependent whether stdio streams are flushed and
whether temporary are removed. In part, this change appears to
be because POSIX.1-2001 added text related to this point.
However, that seems to have been an error in POSIX, and the
text was subsequently removed for POSIX.1-2008. See
https://collaboration.opengroup.org/austin/interps/documents/9984/AI-085.txt
Austin Group Interpretation reference 1003.1-2001 #085
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The 32-bit ARM architecture in Linux has gained a vDSO as of the
4.1 release. (I was the primary author.)
Document the symbols exported by the ARM VDSO.
Accepted kernel submission:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332573.html
Acked-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Glibc 2.17 adds a function to read the frequency at which the Time
Base Register of Power processors is updated.
Signed-off-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think utimensat() and futimens() are thread-safe.
But, there are not markings of utimensat() and futimens() in glibc
document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think pthread_setname_np() and pthread_getname_np()
are thread-safe. But, there are not markings of pthread_setname_np()
and pthread_getname_np() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think pthread_join() is thread-safe. But, there
is not marking of pthread_join() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think pthread_detach() is thread-safe. But, there
is not marking of pthread_detach() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think pthread_create() is thread-safe. But, there
is not marking of pthread_create() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think pthread_cancel() is thread-safe. But, there
is not marking of pthread_cancel() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think pthread_attr_init() and pthread_attr_destroy()
are thread-safe. But, there are not markings of pthread_attr_init()
and pthread_attr_destroy() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- __fpurge: MT-Safe race:stream
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think eventfd() is thread-safe. But, there
is not marking of eventfd() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think clock_getres(), clock_gettime() and
clock_settime() are thread-safe. But, there are not markings of
clock_getres(), clock_gettime() and clock_settime() in glibc document.
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
In the example code you used %x rather than %p in the example
code for an audit library. The problem is that it truncates the
pointers on 64b platforms. So you get something like:
la_symbind64(): symname = strrchr sym->st_value = 0x7f4b8a3f8960
ndx = 222 flags = 0x0 refcook = 8b53e5c8 defcook = 8b537e30
rather than:
la_symbind64(): symname = fclose sym->st_value = 0x7fa452dd49b0
ndx = 1135 flags = 0x0 refcook = 0x7fa453f395c8 defcook = 0x7fa453f32e30
This has bitten me a handful of times when playing around with
audit test libraries to investigate its behavior.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
A long time ago in glibc, repertoire maps were used (but they
were removed already in 2000), those mapping files were named
as mnemonics, so "mnemonic" is a term that would almost
certainly come up if somebody studies glibc side (perhaps even
the related standards like ISO 9945 [which I don't have access
to]) so I thought it's worth to mention to term in the man page
to make sure we're talking about the same thing, otherwise
someone might wonder is that something different or not.
IOW, symbolic names and mnemonics are often used interchangeably,
let's mention the other often used term in the page, too.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
David Rientjes has noticed that MAP_POPULATE wording might promise
much more than the kernel actually provides and intend to provide.
The primary usage of the flag is to pre-fault the range. There is
no guarantee that no major faults will happen later on. The pages
might have been reclaimed by the time the process tries to access
them.
Reviewed-by: Eric B Munson <emunson@akamai.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
MAP_LOCKED had a subtly different semantic from mmap(2)+mlock(2)
since it has been introduced.
mlock(2) fails if the memory range cannot get populated to
guarantee that no future major faults will happen on the range.
mmap(MAP_LOCKED) on the other hand silently succeeds even if
the range was populated only partially.
Fixing this subtle difference in the kernel is rather awkward
because the memory population happens after mm locks have been
dropped and so the cleanup before returning failure (munlock)
could operate on something else than the originally mapped area.
E.g. speculative userspace page fault handler catching SEGV and
doing mmap(fault_addr, MAP_FIXED|MAP_LOCKED) might discard portion
of a racing mmap and lead to lost data. Although it is not clear
whether such a usage would be valid, mmap page doesn't explicitly
describe requirements for threaded applications so we cannot
exclude this possibility.
This patch makes the semantic of MAP_LOCKED explicit and suggests
using mmap + mlock as the only way to guarantee no later major
page faults.
Reviewed-by: Eric B Munson <emunson@akamai.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- sigaltstack: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- sem_open: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think psiginfo() is thread-safe. But, there
is not marking of psiginfo() in glibc document.
psignal() matches glibc marking.
- psignal: MT-Safe locale
- psiginfo: MT-Safe locale
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think mq_notify() is thread-safe. But, there
is not marking of mq_notify() in glibc document.
- mq_notify: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think malloc_stats() is thread-safe. But, there
is not marking of malloc_stats() in glibc document.
- malloc_stats: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think malloc_info() is thread-safe. But, there
is not marking of malloc_info() in glibc document.
- malloc_info: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The marking matches glibc marking.
The marking of functions in glibc is:
- getrusage: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
After research, We think prlimit() is thread-safe. But, there
is not marking of prlimit() in glibc document.
getrlimit() and setrlimit() match glibc markings.
- getrlimit: MT-Safe
- setrlimit: MT-Safe
- prlimit: MT-Safe
Signed-off-by: Zeng Linggang <zenglg.jy@cn.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Marko Myllynen