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 - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply via email to