Date: Tue, 12 Jun 2007 08:42:04 -0700 From: Sam Leffler <sam@errno.com> To: Jeff Roberson <jeff@FreeBSD.org> Cc: cvs-src@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: <466EBECC.3000802@errno.com> In-Reply-To: <200706120724.l5C7Olwd088327@repoman.freebsd.org> References: <200706120724.l5C7Olwd088327@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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). Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?466EBECC.3000802>