Re: Problems about fork-not-clone (was: Re: [uml-user] UML exits after "tracing thread pid")

[Blaisorblade <bla...@ya...>]

(Oleg, this is about your problem, and there are some questions for you too, 
marked with ////////////////////////////, please ACK me about this message).

On Thursday 07 July 2005 13:59, Jeff Dike wrote:
> > Ok, can you describe it a bit more detailedly?

> > Also, are you going to drop this patch (or allow me to do this) for now?
> > Since it isn't getting fixed, it seems me a good idea.

> I still think the patch is correct.
...
> So, I would say that skas0 is more a fix for this problem than
> reverting the fork-not-clone patch is.
For the question above, and from the "stability" point of view, this does not 
matter, even because this patch is not a bug-fix (Valgrind users can apply it 
manually).

> Ben LaHaise sent me a UML binary 
> which crashes, which I can send you if you want to look at it.
Ok, thanks.
> This thing was looking at errno after the first call to fork even if
> it succeeded.
Were you debugging it? Was it using the "errno" variable or calling, as it 
should have done with normal glibc's, __errno_location()?

> This leads me to believe that this is a compiler oddity 
> rather than a compiler bug, and that this is causing UML to hit the
> tt-specific errno crash with recent libcs.
Mmh, I've read "[uml-user] UML at Fedora Core 4 in TT mode: something wrong 
with errno." from Oleg, and it describes the problem well: errno remains 
forever at 0.

But the return values are not altered, in that case, i.e. failure is failure 
and success is success, just errno is not updated.
> You understand that 
> problem more than I do.
Ok, I've never seen it on my own, but I guess I understand it anyway. The 
problem is that:

a) .thread_private is ignored by NPTL
b) so, while for UML (or at least parts of it) the errno is at one place, for 
the libraries (which are already linked) the real, thread-specific (TLS) 
value of errno is used... and using clone()/fork() interferes with this.

I guess that in NPTL headers, instead of using __errno_location() the faster 
"__thread int errno;" is used; Oleg, can you verify this?
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
> So, I would say that skas0 is more a fix for this problem than
> reverting the fork-not-clone patch is.

Wait a moment, the "errno" problem is fixable and currently it should be 
fixed, for what I can see, the patch is in -rc1... though I have problems 
with this, which could stem from a SYSEMU bug (see other thread "Please test 
2.6.13-rc2 in TT mode!"):

is it possible that after calling mmap2(), the value stored in EBX (i.e. the 
first syscall param) is altered? In fact, this is what seems to happen inside 
switcheroo() to the "to" param, leading to the routine errouneously failing. 
This does not happen anywhere else in the UML kernel, it seems.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.beta.messenger.yahoo.com