The statement "conferring permitted or effective capabilities"
to the process is somewhat redundant. Binaries with capabilities
confer capabilities only to those process capability sets, so it's
simpler to just say"confers capabilities to the process".
Reported-by: Yubin Ruan <ablacktshirt@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
At the current man page for shmat(2)[1], there is no mentioning
whether the returned memory address of shmat(2) will be page size
aligned or not. As that is quite important to many applications(e.g.,
those that use locks heavily and would like to avoid some locks by
some atomic guarantees provided by the CPU), it would be great to
specify that for Linux.
I walked down the current implementation of shmat(2) in the latest
kernel src and found that shmat(2) does return a page size aligned
memory address:
SYSCALL_DEFINE3(shmat, int, shmid, char __user *, shmaddr, int, shmflg)
-> do_shmat(...)
-> do_mmap_pgoff(...)
-> do_mmap(...)
-> get_unmapped_area(...)
-> get_area(...) -> offset_in_page(addr)
there is a `offset_in_page(addr)' assertion at the end and if that is
true a -EINVAL would be returned, by which we can be sure that
shmat(2) will return a page size aligned memory address on success[2].
[1]: http://man7.org/linux/man-pages/man2/shmat.2.html
[2]: there is also a `offset_in_page(2)' in get_unmapped_area(...),
but that doesn't lead to -EINVAL...I am not sure whether the logic of
that code is right.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Expand and rework the text a little, in particular adding
a reference to sigreturn(2) as a source of further
information about the ucontext argument.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Remove reference to non-standard "tlpi_hdr.h" and replace calls to
functions that were declared in this header.
Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reviewed-by: Mike Kravetz <mike.kravetz@oracle.com>
Reviewed-by: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Currently, the backtrace(3) manual page says this about backtrace_symbols_fd():
back‐
trace_symbols_fd() does not call malloc(3), and so can be
employed in situations where the latter function might fail.
However, I watched a video of a presentation about signal handling and
the speaker was saying that calling backtrace() can trigger a call to
malloc - indirectly. That happens because the backtrace*() functions
are part of libgcc, which gets dynamically loaded whenever needed;
dynamic loading would, in turn, trigger a malloc. The talk can be
found here: http://free-electrons.com/pub/video/2008/ols/ols2008-gilad-ben-yossef-fault-handlers.ogg
I decided to test it out, and it seems that this is still true (at
least on Ubuntu 12.04). I compiled the attached program (I used
CXXFLAGS = '-Wall -g -std=c++0x', the -std= part is not really needed)
and ran it through gdb, putting a breakpoint on the line where
backtrace is called. When that breakpoint is hit, I set a breakpoint
on malloc, continued and voila:
Breakpoint 2, __GI___libc_malloc (bytes=36) at malloc.c:2910
2910 malloc.c: No such file or directory.
(gdb) bt
"/lib/x86_64-linux-gnu/libgcc_s.so.1") at dl-load.c:162
"libgcc_s.so.1", type=2, trace_mode=0, mode=-1879048191,
nsid=<optimized out>) at dl-load.c:2473
errstring=0x7fffffffdd00, mallocedp=0x7fffffffdd0f,
operate=0x7ffff7ded700 <dl_open_worker>, args=0x7fffffffdcb0) at
dl-error.c:178
"libgcc_s.so.1", mode=-2147483647, caller_dlopen=0x7ffff7b260a9,
nsid=-2, argc=1, argv=<optimized out>, env=0x7fffffffe068) at
dl-open.c:639
errstring=0x7fffffffded0, mallocedp=0x7fffffffdeef,
operate=0x7ffff7b4bc20 <do_dlopen>, args=0x7fffffffdeb0) at
dl-error.c:178
operate=0x7ffff7b4bc20 <do_dlopen>) at dl-libc.c:48
out>) at dl-libc.c:165
../sysdeps/x86_64/../ia64/backtrace.c:104
Reviewed-by: Walter Harms <wharms@bfs.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As reported by Rahul, the existing sentence could be read as
meaning that resources of joined and terminated detached
threads are freed at only at process termination. Eliminate
that possible misreading.
Reported-by: Rahul Bedarkar <rpal143@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk