Calls to getpid() in clone'd child return parent's pid.

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Calls to getpid() in clone'd child return parent's pid.

Carlos O'Donell-2
libc-ports,

For the following tests:
nptl/tst-align2.c
nptl/tst-getpid1.c
nptl/tst-getpid2.c

I'm seeing that calls to getpid() in the clone'd child return the parent's pid.
If I make a raw syscall e.g. syscall(__NR_getpid), this returns the correct
pid. Is this problem indicative of anything in particular?

For example on hppa-linux, the cloned child will inhereit the value of the
parents thread register. The nptl getpid() wrapper will therefore return
the parents pid.

How is this supposed to work when the clone flags are zero?

Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

Re: Calls to getpid() in clone'd child return parent's pid.

Daniel Jacobowitz-2
On Wed, Sep 13, 2006 at 10:10:31PM -0400, Carlos O'Donell wrote:
> I'm seeing that calls to getpid() in the clone'd child return the parent's
> pid.
> If I make a raw syscall e.g. syscall(__NR_getpid), this returns the correct
> pid. Is this problem indicative of anything in particular?

Failure to handle RESET_PID in your clone.S, maybe?

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: Calls to getpid() in clone'd child return parent's pid.

Carlos O'Donell-2
On 9/13/06, Daniel Jacobowitz <[hidden email]> wrote:
> Failure to handle RESET_PID in your clone.S, maybe?

That is correct, we are not handling RESET_PID at all.
After reading a couple of implementations it looks like we
need to do the following:

#ifdef RESET_PID
- In the cloned child, before calling the clones function.
- Skip this if CLONE_THREAD or CLONE_VM
- Call the getpid syscall, and store the result in PID and TID (tcb-offsets.h).
#endif

Does that look right?

Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

Re: Calls to getpid() in clone'd child return parent's pid.

Daniel Jacobowitz-2
On Thu, Sep 14, 2006 at 12:02:50AM -0400, Carlos O'Donell wrote:

> On 9/13/06, Daniel Jacobowitz <[hidden email]> wrote:
> >Failure to handle RESET_PID in your clone.S, maybe?
>
> That is correct, we are not handling RESET_PID at all.
> After reading a couple of implementations it looks like we
> need to do the following:
>
> #ifdef RESET_PID
> - In the cloned child, before calling the clones function.
> - Skip this if CLONE_THREAD or CLONE_VM
> - Call the getpid syscall, and store the result in PID and TID
> (tcb-offsets.h).
> #endif
>
> Does that look right?

I've got no idea any more :-)  But not quite - I distinctly remember
some CLONE_VM handling.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: Calls to getpid() in clone'd child return parent's pid.

Carlos O'Donell-2
On 9/14/06, Daniel Jacobowitz <[hidden email]> wrote:
> I've got no idea any more :-)  But not quite - I distinctly remember
> some CLONE_VM handling.

It seems to be:

If CLONE_THREAD was set, skip touching the thread's PID/TID
If CLONE_VM was set, write -1 into the PID/TID
If neither CLONE_THREAD or CLONE_VM was set, then call
__NR_getpid and write that result into PID/TID.

If someone more knowledgable could respond that would rock.
My RESET_PID patch fixes tst-getpid1/2 and tst-align2, but
causes tst-cond16 and tst-cond17 to fail with:

pthread_mutex_lock.c:82: __pthread_mutex_lock: Assertion
`mutex->__data.__owner == 0' failed.

I it is sensitive to PID/TID because __owner is set to TID. The call
to do_clone, and subsequently ARCH_CLONE, has CLONE_VM set, but not
CLONE_THREAD. Therefore I am worried that writing "-1" into PID/TID is
incorrect.

Cheers,
Carlos.