lkml.org 
[lkml]   [2004]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectFixing UML against NPTL (was: Re: [uml-devel] [PATCH] UML: Use PTRACE_KILL instead of SIGKILL to kill host-OS processes (take #2))
Date
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 14:07    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site