From owner-cvs-all Tue Mar 6 13: 0:35 2001 Delivered-To: cvs-all@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id CE57037B71A; Tue, 6 Mar 2001 13:00:26 -0800 (PST) (envelope-from gibbs@scsiguy.com) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f26L0PO08347; Tue, 6 Mar 2001 14:00:26 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200103062100.f26L0PO08347@aslan.scsiguy.com> To: John Baldwin Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_intr.c src/sys/sys interrupt.h In-Reply-To: Your message of "Sun, 04 Mar 2001 15:11:11 PST." Date: Tue, 06 Mar 2001 14:00:25 -0700 From: "Justin T. Gibbs" Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >You can't free it before it is run, but you can free it while it is already >running. That's a question of semantics I suppose. There must be a window between when you last check to see if the handler is dead and you actually get to a point in the interrupt handler where you could acquire some other lock that might protect your data from going away. To me that is being freed before being run. > A tsleep/wakeup pair between ithread_remove_handler() and >ithread_loop() can be used to work around this, however. Untested patch >included below. I haven't tested this either, but it should work. We should also update the manual page to indicate that you must deregister from a context that can sleep. In SMPNG, there should be very few places where you can't sleep. >The IH_DEAD flag is the state in question. However, one thing I may play with >is just locking the list with a mutex at some point in time, as it may not end >up being all that expensivem, esp. since it would almost always be >non-contested. Not sure about this yet, though. Unecessary locks are, unecessary. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message