Date: Tue, 12 Jun 2007 11:55:40 -0700 (PDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Sam Leffler <sam@errno.com> Cc: cvs-src@FreeBSD.org, Jeff Roberson <jeff@FreeBSD.org>, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/sys proc.h src/sys/kern kern_thread.c Message-ID: <20070612115310.C60816@10.0.0.1> In-Reply-To: <466EBECC.3000802@errno.com> References: <200706120724.l5C7Olwd088327@repoman.freebsd.org> <466EBECC.3000802@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 12 Jun 2007, Sam Leffler wrote: > Jeff Roberson wrote: >> jeff 2007-06-12 07:24:47 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/sys proc.h sys/kern kern_thread.c >> Log: >> Solve a complex exit race introduced with thread_lock: >> - Add a count of exiting threads, p_exitthreads, to struct proc. >> - Increment p_exithreads when we set the deadthread in thread_exit(). >> - When we thread_stash() a deadthread use an atomic to drop the count. >> - Spin until the p_exithreads count reaches 0 in thread_wait(). >> - Lock the last exiting thread momentarily to be certain that it has >> exited cpu_throw(). >> - Restructure thread_wait(). It does not need a loop as there will only >> ever be one thread. > > What are the symptoms of this race? Since the sched lock changes I've > repeatedly hit user-after-free crashes and other data corruption-like assert > failures that appear to trigger through signals and exit. These are all on > UP (laptops). I hadn't heard of these problems. This race is not possible on UP. On MP you could have had a NULL deref in cpu_throw(). UP should have been relatively unchanged as a result of threadlock and was tested under heavy load. Can you describe the problems you're seeing in any further detail? Thanks, Jeff > > Sam >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070612115310.C60816>