Date: Sat, 03 Mar 2001 17:32:51 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_intr.c src/sys/sys interrupt.h Message-ID: <XFMail.010303173251.jhb@FreeBSD.org> In-Reply-To: <200103040049.f240ncO75112@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04-Mar-01 Justin T. Gibbs wrote: >>jhb 2001/02/21 18:18:33 PST >> >> Modified files: >> sys/kern kern_intr.c >> sys/sys interrupt.h >> Log: >> Work around a race condition where an interrupt handler can be removed from >> an interrupt thread while the interrupt thread is blocked on Giant waiting >> to execute the interrupt handler being removed. > > Isn't there still a race for a driver trying to deregister its handler > while an interrupt is running or about to run? It seems to me that the > unregister call should block (spin?) until it is guaranteed that the hander > is not executing and can never be called again. When an interrupt handler is removed, we mark the handler as dead if the thread is runnable. We do this with a spin lock held to prevent new interrupts from coming in while we do this. If the thread is runnable, then on a UP system the ithread isn't running. When the ithread wakes up, it has either already run the handler (in which case we don't care), it is running the handler, or it is about to run the handler. If it is about to run the handler, then we will see the IH_DEAD flag and remove the handler. If it is in the handler, there's nothing we can really do. Now, it does become worse on an SMP system if the ithread in question is running on another CPU while we are removing the handler. In that case, we will mark it dead as before. Now, the ithread over on the other side can be in the same state as the resuming ithread above. If we haven't got there yet, it will be removed ok. If we are currently executing it, there's nothing we can do about it. If we have passed it, then the setting of it_need ensures we will traverse the list of handlers again and remove the handler in that pass. I'm not sure how one would work around the problem where a handler could be removed while the ithread is in that handler's actual function. The only way I can think of to do it is to lock the list in the ithread as well each time we get an interrupt, and if you think interrupt latency is bad now. In fact, it would have to be a sleep lock or possibly a reader/writer lcok so that interrupt handlers can safely grab their own mutexes without causing problems. However, it may be that a sleep mutex wouldn't be but so evil. If desired I can whip up a patch to do that instead and see how much worse it is. It would probably hurt lpr performance a bit unless the ppbus was fixed to do its own multiplexing of the interrupt. > -- > Justin -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010303173251.jhb>