Date: Mon, 21 Dec 1998 16:30:41 +1030 From: Greg Lehey <grog@lemis.com> To: Alfred Perlstein <bright@hotjobs.com>, hackers@FreeBSD.ORG Subject: Re: question about re-entrancy. Message-ID: <19981221163041.C24125@freebie.lemis.com> In-Reply-To: <Pine.BSF.4.05.9812201621560.6331-100000@bright.fx.genx.net>; from Alfred Perlstein on Sun, Dec 20, 1998 at 04:36:51PM -0500 References: <Pine.BSF.4.05.9812201621560.6331-100000@bright.fx.genx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, 20 December 1998 at 16:36:51 -0500, Alfred Perlstein wrote: > > I'm a bit confused. I've been watching the discussions going on about > SMP. The issue of kernel re-entrancy has been brought up many times. > > So here's the question: > > I thought the kernel was re-entrant, when a process makes a syscall it's > thread of execution enters the kernel where its arguments are validated > and careful checks are done to ensure security then the syscall is done. Well, those are two different things. AFAIK the kernel is *not* reentrant, in the sense that only one process can be executing in the kernel at any one point. Certainly the classical UNIX kernel is not, anyway, but it makes sense to allow concurrent execution on SMP machines. I believe that at the moment, though, the kernel does not allow this. On the other hand, of course the kernel checks parameters for validity and protects itself. > If during the system call the process is put to sleep or rescheduled, > another process may enter the kernel. Right. That's the only way, but then the process isn't executing. > As long as the splxxx() calls do not interfere with each other you > have 2 processes excuting in the kernel at that point. (more can > enter as well) You seem to be confused here. splxxx() is an interrupt-level mechanism, and it's not needed for resources which are accessed by processes (i.e. non-interrupt environments) alone. > Or.... what i'm now thinking is that once a process enters the kernel it > must run until it exits the system call. Or it gets suspended. > I have a problem with this though, processes such as nfsiod/nfsd > enter the kernel through a syscall and never exit (according to > design and implementation) how then are other processes allowed into > the kernel? The normal state of all daemons is sleeping. > Can anyone explain this a bit better? > > I understand deadlock can occur if something like this happens: > > process 1 process 2 > syscall() > splbio() > rescheduled -----> This can't happen, not inside splbio(). How can it get rescheduled? > syscall() > splimp() > <----- rescheduled > splimp()? -no,reschedule-> > <-no,reschedule- splbio()? > splimp()? -no,reschedule-> > splbio()? > > some sorta flipflop deadlock happens at this point as nested locks are > held and won't be released as two in kernel processes never relinquish > resources. > > Or are the spl calls simply there to diable interupts? Yes, that's exactly what they do. > but that brings me back to the question about "well how do nfsd and > nfsiod do it?" They don't sleep inside spl()s. > Perhaps once an spl is initiated the process can not block? Right. > the more I thought about this, the more my head ached :) You'd probably find ``The Design and Implementation'' a useful read. It'll give you a better understanding of the issues. But it seems to me that you're attributing more importance to the splxxx() functions than they deserve. To recap: you don't need to synchronize between processes, because the kernel (currently) guarantees that only one process will be doing something in the kernel at any one time. On the other hand, non-process activity (interrupts, bottom halves of device drivers) can execute at just about any time. You resolve conflicts between interrupt handlers and possibly the process currently running by locking out specific interrupts in critical sections of code. That's what the splxxx() routines do. In the PDP-11, they set the processor priority level (which is why you'll occasionally see the System Visms spl4(), spl5(), spl6() and spl7()). On the i386, they mask specific interrupts relating to the function (for example, splbio() masks disk controller/host adaptor interrupts). Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981221163041.C24125>