Date: Wed, 27 Aug 1997 15:54:21 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: smp@csn.net (Steve Passe) Cc: terry@lambert.org, petrilli@amber.org, mestery@winternet.com, peters@gil.com.au, smp@FreeBSD.ORG Subject: Re: A how does it work question. Message-ID: <199708272254.PAA00730@phaeton.artisoft.com> In-Reply-To: <199708272244.QAA00398@Ilsa.StevesCafe.com> from "Steve Passe" at Aug 27, 97 04:44:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> ISR from being run concurrently, eg CPU0 for an INT on tty0 and CPU1 for an > INT on tty1. There are global variables in sio.c that would fail if used > concurrantly. So the driver is not kernel reeentrant on seperate device contexts. That's what I said, 8-). For this driver, you'd set the flag. For other drivers (or the sio driver, as a template?) you wouldn't, because reentrering on different devices isn't fatal once the globals have been taken care of. But you are banging on the non-Fast ints right now, so you are going to hit that sooner or later anyway. > > The flag I'm talking about is a "this driver may be reentered" flag; > > are you saying it's possible to reenter it on the same CPU, but not > > on a different CPU? That' might be one issue, but I don't think > > that would qualify for the MPSAFE flag... > > no, there should be no distinction as to CPU, but you obviously can't > reenter a fast interrupt from the same CPU, as fast ISRs run to completion, ie > they can't be interrupted by themselves. But they could interrupt another > CPU which would then attempt to enter the same ISR without the OUTER lock > in place to prevent it. Right. All I'm saying is "make the assertion of the outer lock conditional on the existane of a driver flag". This will let you have some drivers that are kernel reentrant and some that aren't; I guess there is still the issue of reentering on a CPU, but the ISR dispatch should prevent that from happening anyway, right? I mean sevicing an interrupt must not be interrupted -- that's what the SPL stuff does. Yes, I know, the fastintr stuff is a special case, since another interrupt should not be permitted on the same CPU until it completes, but that's not the case for the SPL protected regular INTs. I guess I just assumed that the current fastintr code already protects against reentry on a per kernel basis, and that should be a per CPU basis instead. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708272254.PAA00730>