Bug#857909: [libc6-dev] getpid() in child process created using clone(CLONE_VM) returns parent's pid
On 03/17/2017 10:30 AM, Kirill Tkhai wrote:
> I interpret the below paragraph as the only "stale-cache" case:
>>> In particular, if a signal is delivered to the child immediately after the clone()
>>> call, then a call to getpid(2) in a handler for the signal may return the PID of the calling
>>> process ("the parent"), if the clone wrapper has not yet had a chance to update the PID cache in
>>> the child.
No, this is just one example. "In particular" does not mean that this is the only case
where this applies, just a very noteworthy one. It's not exclusive to this case.
> Also, there is
>>> The stale-cache problem also does not occur if the flags argument includes CLONE_VM.
> Isn't it the case of my test program?
Yes, but I'd still argue that the overall statement for getpid() is "We don't guarantee
that the information provided by getpid() is correct and we therefore recommend you
to use the syscall." Whether this flag makes a difference to the overall reliability
of getpid() or not is questionable.
I did a quick check on Jessie and it seems that at least the statement for CLONE_VM
is true there, although as you can see from the output below, the process scheduling
from the kernel side seems to be different with the terminal output already returning
to bash before the child has a chance to print to the terminal:
parent: fork pid=1321
glaubitz@jessie64:~> 1)child: pid=1321
I would suggest filing a bug report to glibc upstream or posting on their mailing list
to ask for feedback. I honestly don't know how acceptable the stale cache data with
CLONE_VM is, but since the documentation already recommends to using the syscall, I
think its safe to ignore this behavior:
> To get the truth, it may be necessary to use code such as the following:
> #include <syscall.h>
> pid_t mypid;
> mypid = syscall(SYS_getpid);
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - email@example.com
`. `' Freie Universitaet Berlin - firstname.lastname@example.org
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913