See https://bugzilla.kernel.org/show_bug.cgi?id=25292
And there will likely be future changes as well.
Quoting http://www.opengroup.org/austin/aardvark/latest/xshbug3.txt:
COMMENT Enhancement Request Number 15
rajani.g.k:xxxxxx Defect in XSH 2.4.3 (rdvk# 6)
{GKRFORK012009} Thu, 8 Jan 2009 07:41:10 GMT
[...]
As per this section, XSH P1529, L49389-49402, it is possible
that multithreaded libraries could be used by single threaded
applications. In which case, atfork handlers are essential for
the libraries to protect their internal state during fork. As
explained further P1530, L49403-49404, pthread_atfork
functions are mainly required to acquire/release mutex locks,
for protecting the applications/libraries from fork() calls.
C-library needs to as well have an atfork handler which
acquires all the required locks to protect its memory state
across fork().
The acquire/release mutex calls themselves are aync-signal
unsafe operations. Use of them makes pthread_atfork handlers
async-signal unsafe which in turn makes fork() async-signal
unsafe when called by an application which is multi threaded,
or which is linked to a library which is multi threaded.
Action:
Need clarification with respect to
1. Is it correct to list fork as an async-signal safe
interface, in a multi threaded scenario?
2. Can the implementation be allowed to not call the atfor
handlers, when fork is called from a signal handler? If the
atfork handlers are not going to be called when fork is called
in the signal handler, then they can not be called, even if
fork is called in the newly created child before exec.
3. If only async-signal safe functions are to be called from
pthread_atfork handlers, then how will multi-threaded librarie
protect themselves by the fork calls, made by single threaded
applications linked to them?
Reported-by: KASAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Also:
* add more detail on changes across standards
* provide proper section cross references in function references
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
I'd say this is fair use (many other man pages do the same).
So, no need to clutter the man page source with this information.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This is my writeup of a basic description of /dev/fuse after
playing with it for a few hours today. It is of course woefully
incomplete, and since I neither have a use case nor am working
on this code, I will not be in a position to expand it in the
near future. However, I'm hoping this could still serve as a
handy reference for others looking at this interface.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The FDs returned by NS_GET_USERNS and NS_GET_PAREENT must be
tested by comparing to both the 'st_dev' and 'st_ino' fields
returned by fstat(2).
Reported-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This section material in the user_namespaces(7) page was written
before the creation of the mount_namespaces(7) manual page.
Nowadays, this material properly belongs in the newer page.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk