Fixing UML against NPTL (was: Re: [uml-devel] [PATCH] UML: Use PTRACE_KILL instead of SIGKILL to kill host-OS processes (take #2))

[Blaisorblade <blaisorblade_spam@yahoo.it>]

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

On Thursday 04 November 2004 01:39, Chris Wedgwood wrote:
> On Thu, Nov 04, 2004 at 01:13:27AM +0100, Blaisorblade wrote:
> > Well, not a lot of new work should go there.
>
> agreed
>
> > Not always. Do you think I'm a luser? Or what?
>
> no, not at all
>
> i was asking what break to see if i can help

Intimate Linking Script and NPTL knowledge would help a lot.

The issues are 2 ones:

1) LKML does not link because the linker does not like it's linker script, 
which defines a special thread_private section (give a look at switcheroo() 
and you could maybe realize the issue of copying the .text to a tmpfs file 
and replacing the mapping to the executable with the tmpfs file mapping).

2) getpid() on a child clone returns the process's pid when run with a 
NPTL-enabled glibc, while it returns the thread pid with a LinuxThreads one; 
this causes tons of problems with UML, which uses signals as inter-thread and 
intra-thread communication.

Note UML is not using pthread_create() to create the threads, where this 
behaviour is an improvement. I'm using a plain clone() call without the 
CLONE_THREAD flag (which is not even added in by glibc, according to strace).

I've not yet checked if glibc is hijacking getpid() or not, but that would be 
strange anyway.

Also, this behaviour has been reported the first time about at the time of 
2.6.0, but actually UML has almost never runs against NPTL glibc, because 
it's statically linked most times.

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

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