Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Dec 2007 23:53:02 -0500 (EST)
From:      Daniel Eischen <deischen@freebsd.org>
To:        David Xu <davidxu@freebsd.org>
Cc:        nate@yogotech.com, java@freebsd.org, julian@freebsd.org
Subject:   Re: cvs commit: src/lib/libkse/thread thr_kern.c
Message-ID:  <Pine.GSO.4.64.0712022341210.17493@sea.ntplx.net>
In-Reply-To: <47536361.8090203@freebsd.org>
References:  <200711301716.lAUHGEV1064334@repoman.freebsd.org> <wpprxrto0s.fsf@heho.snv.jussieu.fr> <Pine.GSO.4.64.0711301659060.5465@sea.ntplx.net> <wpwsrz9uyr.fsf@heho.snv.jussieu.fr> <Pine.GSO.4.64.0711301849310.6581@sea.ntplx.net> <47536361.8090203@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 3 Dec 2007, David Xu wrote:

> Daniel Eischen wrote:
>> 
>> 
>> Yes, this would seem to be a kernel problem, as _get_curthread()
>> seems to be returning garbage.  This is a libkse MD function,
>> that relies on %gs (for i386/amd64) to point to something
>> that was initialized in the parent.
>> 
>> Julian, David, got any ideas?
>> 
>
> I don't know, I am still reading some kernel code.

I think it is possible that the fork()ing thread blocks
before the vm space is copied to the child and an upcall is
made.  The curthread is changed before the vm space is copied
(or set to NULL) in the parent KSE/thread.  Then the child
thread/process unblocks and completes, getting a copy of the
vm space with curthread set to an invalid value (NULL or
another now non-existent thread).

I'm not sure what is suppose to happen with fork() in this
case.  Perhaps I should just commit the patch to work around
the problem, or put the KSE in a critical region across a
fork() so that an upcall doesn't happen.

I'm not sure why libthr has similar problems, although harder
to reproduce.  This would seem a problem limited to libkse.

-- 
DE



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0712022341210.17493>