From owner-cvs-src@FreeBSD.ORG Thu Oct 25 02:26:07 2007 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C946A16A501; Thu, 25 Oct 2007 02:26:07 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id A505913C48A; Thu, 25 Oct 2007 02:26:07 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 775511A4D81; Wed, 24 Oct 2007 19:26:07 -0700 (PDT) Date: Wed, 24 Oct 2007 19:26:07 -0700 From: Alfred Perlstein To: David Xu Message-ID: <20071025022607.GQ33488@elvis.mu.org> References: <200710231754.l9NHsGLH090312@repoman.freebsd.org> <471FF2BE.9000204@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <471FF2BE.9000204@freebsd.org> User-Agent: Mutt/1.4.2.3i 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:26:07 -0000 * 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. -- - Alfred Perlstein