Date: Thu, 25 Oct 2007 10:33:08 +0800 From: David Xu <davidxu@FreeBSD.org> To: Alfred Perlstein <alfred@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Julian Elischer <julian@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_fork.c Message-ID: <47200064.9050403@freebsd.org> In-Reply-To: <20071025022607.GQ33488@elvis.mu.org> References: <200710231754.l9NHsGLH090312@repoman.freebsd.org> <471FF2BE.9000204@freebsd.org> <20071025022607.GQ33488@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > * David Xu <davidxu@FreeBSD.org> [071024 18:34] wrote: > >>Julian Elischer wrote: >> >>>julian 2007-10-23 17:54:16 UTC >>> >>> FreeBSD src repository >>> >>> Modified files: >>> sys/kern kern_fork.c >>> Log: >>> Take out the single-threading code in fork. >>> After discussions with jeff, alc, (various Ironport people), david Xu, >>> and mostly Alfred (who found the problem) it has been demonstrated that >>> this >>> is not needed for our implementations of threads and represents a real >>> (as in we've seen it happen a lot) deadlock danger. >>>... >> >>I think if process is forking a thread, that says flag RFPROC is not >>set and flags RFCFDG or RFCFDG is set, you still need to call >>thread_single(SINGLE_BOUNDARY), otherwise, for a threaded process, >>the memory pointed by p_fd is freed while other threads are using it, >>it will cause kernel to panic. > > > This is unlikely to be fixed by SINGLE_BOUNDARY and will likely require > refcounting to fix. SINGLE_BOUNDARY will not fix the locations where > this happens: > > p = td->td_proc; > fdp = p->p_fd; > do something that blocks... > re-use fdp. > thread_suspend_check() with SINGLE_BOUNDARY is used is only called in userret() where I don't think any code is still using the p_fd. Regards, David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47200064.9050403>