Date: Wed, 24 Oct 2007 19:26:07 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: David Xu <davidxu@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: <20071025022607.GQ33488@elvis.mu.org> In-Reply-To: <471FF2BE.9000204@freebsd.org> References: <200710231754.l9NHsGLH090312@repoman.freebsd.org> <471FF2BE.9000204@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* 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.
--
- Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071025022607.GQ33488>