Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Oct 1999 00:08:47 -0600
From:      Warner Losh <imp@village.org>
To:        arch@freebsd.org
Subject:   Racing interrupts
Message-ID:  <199910240608.AAA34462@harmony.village.org>

next in thread | raw e-mail | index | archive | help

Consider the following situation.  There is a driver talking to a
device.  An unmasked interrupt happens and the device is now gone.
How does the driver know to stop what it is doing and respond to this
disappearance in a sane way?

This sort of situation comes up in the pccard code.  When someone
ejects the card, an interrupt fires.  If I were to remove the device
from the tree in the interrupt handler, I can invalidate the softc
that the driver is still using by freeing it.  At that point the
driver is running out of freed memory and all bets are off.

I can schedule a timeout to happen in 0 clock ticks so that it is then
"safe" to remove the device, but the hardware is either gone or very
close to being gone when the first interrupt happens, so we've moved
the problem from memory corruption to a hardware hang.

It would be nice if there was some way to ref/unref the use of softc
so I could remove the device right away, but defer the actual removal
of the device and softc until the last deref of softc.  This strikes
me as a major PITA and may still result in a hardware hang.

It is my understanding that the pccard hardware still still exist for
a period of time after the card is ejected (since it takes some period
of time to move from the pins that caused the interrupt to the
power/control/data pins being disabled).  I don't know if this is
true, or if true what the period of time is.

What I really want is a kernel signal mechanism which will start a
rundown of the driver thread which is not allowed to touch hardware,
but can only free resources used by the driver.  We have lots of tight
loops in drivers in the kernel and it seems unwise to pessimize those
so that this race can be dealt with...

Comments?

Warner





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910240608.AAA34462>