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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
