Re: [uml-devel] Re: Stop at startup on 2.6 NPTL hosts

[Blaisorblade <blaisorblade_spam@yahoo.it>]

[-- Attachment #1: Type: text/plain, Size: 3840 bytes --]

On Tuesday 09 November 2004 17:42, Bodo Stroesser wrote:
> Blaisorblade wrote:
> > On Friday 29 October 2004 11:26, Roland Kaeser wrote:
> > This is executed by a clone() child. What happens is that, with NPTL,
> > both the father and the son have the same pid, so the SIGSTOP is routed
> > to the wrong thread. However, this is not expected: having the same pid
> > should be reserved to when clone is called with CLONE_THREAD in the
> > flags. I've verified that this is not happening in this case, even with
> > strace (to make sure glibc is not playing any dirty tricks). But for some
> > reasons, the kernel is behaving as if this happened.

> Sorry, I have to oppose. The threads don't have the same pid! Only the
> getpid()- call to the lib returns the pid of the father.

This makes much more sense than my thoughts. I said I was going to investigate 
on that, but had no time yet.

This fact (glibc caches getpid() results) was even known because already 
posted, and I guessed that this could happen only with TLS support.

Also, not a lot of days ago, I was thinking to this issue for the UML startup 
tests (they rely on ptrace() catching the syscall done by the child and 
modifying it, so they would fail with the caching).

Still, I didn't realize this was the problem. Thanks for your help, as always.

> I wrote a small test program (attached). Please compile it with:
>
>     gcc -static -o test_getpid_static test_getpid.c        and
>     gcc -o test_getpid_nptl test_getpid.c

> Using the two programs, you can see the following:

> 1) having linked my test with -static, each "getpid()" in the test results
> in a syscall (try "strace test_getpid_static")
> 2) linking without -static (I assume, this means using NPTL), only the
> first getpid() does a syscall, I guess, the further calls deliver a
> pid-value buffered in the lib! (try "strace test_getpid_static")
> The test here requests and prints out its pid twice, then it exits. But
> strace will show you two getpid()-calls only in case of the _static
> program.

> 3) the pid-history seen in 1 and 2 is used even for a child created with
> "clone()", regardless which clone-flags are used! Try "test_getpid_static
> clone" and "test_getpid_nptl clone" to see, what happens.

>     After printing its pid twice, the program now creates a child via
> "clone()". The child requests its *real* pid via a "by-hand-syscall". Than
> it stops itself and is ptraced by the father, which prints out a message,
> if the child does a *real* getpid()-syscall.

>     Note: If you remove the two getpid()-calls at the beginning of main(),
> the child will work correctly even with NPTL, since there isn't yet a
> buffered pid ...

> Summary: I guess, the behavior of NPTL is a bug. Do you agree? To which
> list should a bugreport be mailed?

I don't think it's exactly a bug, but it could be more of a pitfall. Why? When 
using pthread_create, it will also setup a different per-thread TLS area.

Now, the question is: clone() is a syscall, so no such setup is done. Is it 
correct to wrap it to do this?

However, even fork() is a syscall, but I think that it does not have this 
problem. Would you mind testing if fork() correctly works?

I must also say, that I saw, in fact, a clone() wrapper in glibc; only I think 
it's not used when issuing clone() calls, which only do the syscall and a 
little setup to jump to the provided function.

Anyway, it must documented in getpid() and clone() man-pages, at least.

> To work around, we could use the by-hand-syscall for os_getpid(). I didn't
> test it, but I'm quite shure, that it fixes the problem.

I'm on the same position. I'm going to test that on my Gentoo host.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]