Date: Wed, 11 Jan 2006 06:56:43 -0700 From: Scott Long <scottl@samsco.org> To: John Baldwin <jhb@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Scott Long <scottl@freebsd.org>, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern subr_taskqueue.c Message-ID: <43C50E9B.5050508@samsco.org> In-Reply-To: <200601110847.08614.jhb@freebsd.org> References: <200601110037.k0B0bDv4009424@repoman.freebsd.org> <200601110847.08614.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Tuesday 10 January 2006 07:37 pm, Scott Long wrote: > >>scottl 2006-01-11 00:37:13 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/kern subr_taskqueue.c >> Log: >> The interlock in taskqueue_terminate() is completely wrong for taskqueues >> that use spinlocks. Remove it for now. > > > Eh? It's waiting for the wakeup that comes from kthread_exit() after the > thread has exited which is locked via the proc lock. Sleeping on the > taskqueue itself doesn't buy you anything. (In fact, it might sleep > forever.) The simplest solution might be to acquire the proc lock a lot > earlier before the taskqueue lock in this function so that you don't have to > acquire it while holding the taskqueue lock since that is what gives you > problems. > With the code the way it was, kthread_exit() in taskqueue_thread_loop can wind up blocking on the proc lock while the lock is still held in taskqueue_terminate. I don't know why this is actually a problem, but turning on WITNESS to investigate revealed the immediate problem of trying to grab the proc lock with a spinlock already held. The interlock is really just a protection against drivers that don't adequately quiesce themselves, so I removed it for now until we can figure out something better. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43C50E9B.5050508>