(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
|