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>