From owner-cvs-src@FreeBSD.ORG Thu Oct 25 02:32:20 2007 Return-Path: Delivered-To: cvs-src@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B21216A419; Thu, 25 Oct 2007 02:32:20 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E243C13C480; Thu, 25 Oct 2007 02:32:19 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from [127.0.0.1] (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l9P2WEeS001078; Thu, 25 Oct 2007 02:32:16 GMT (envelope-from davidxu@freebsd.org) Message-ID: <47200064.9050403@freebsd.org> Date: Thu, 25 Oct 2007 10:33:08 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alfred Perlstein References: <200710231754.l9NHsGLH090312@repoman.freebsd.org> <471FF2BE.9000204@freebsd.org> <20071025022607.GQ33488@elvis.mu.org> In-Reply-To: <20071025022607.GQ33488@elvis.mu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Julian Elischer , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_fork.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2007 02:32:20 -0000 Alfred Perlstein wrote: > * David Xu [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