Bug#857909: [libc6-dev] getpid() in child process created using clone(CLONE_VM) returns parent's pid

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#857909: [libc6-dev] getpid() in child process created using clone(CLONE_VM) returns parent's pid

John Paul Adrian Glaubitz
Hi Kirill!

> My case is not in the list of the cases, described in clone(2),
> when wrong pid may be returned, so this is a BUG.

Which case in particular do you mean? From the manpage it seems that
getpid() is simply not reliable under various circumstances and that
one should always use the syscall alternative if possible:

> Versions  of  the  GNU  C library that include the NPTL threading library contain a wrapper function for getpid(2)
> that performs caching of PIDs.  This caching relies on support in the glibc wrapper for clone(), but as  currently
> implemented,  the  cache  may not be up to date in some circumstances.

Can you elaborate a bit more where your sample code contradicts the
clone(2) manpage which documents the buggy behavior?

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Bug#857909: [libc6-dev] getpid() in child process created using clone(CLONE_VM) returns parent's pid

John Paul Adrian Glaubitz
Hi Kirill!

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:

glaubitz@jessie64:~> ./clone
parent: pid=1320
parent: fork pid=1321
glaubitz@jessie64:~> 1)child: pid=1321
2)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);

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - [hidden email]
`. `'   Freie Universitaet Berlin - [hidden email]
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply | Threaded
Open this post in threaded view
|

Bug#857909: [libc6-dev] getpid() in child process created using clone(CLONE_VM) returns parent's pid

Florian Weimer
* John Paul Adrian Glaubitz:

> I would suggest filing a bug report to glibc upstream or posting on
> their mailing list to ask for feedback.

Upstream has since removed the PID cache:

  <https://sourceware.org/bugzilla/show_bug.cgi?id=19957>
  <https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=0cb313f7cb0e418b3d56f3a2ac69790522ab825d>