Date: Sun, 20 Dec 1998 16:36:51 -0500 (EST) From: Alfred Perlstein <bright@hotjobs.com> To: hackers@FreeBSD.ORG Subject: question about re-entrancy. Message-ID: <Pine.BSF.4.05.9812201621560.6331-100000@bright.fx.genx.net>
next in thread | raw e-mail | index | archive | help
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.
If during the system call the process is put to sleep or rescheduled,
another process may enter the kernel. 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)
Or.... what i'm now thinking is that once a process enters the kernel it
must run until it exits the system call. 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?
Can anyone explain this a bit better?
I understand deadlock can occur if something like this happens:
process 1 process 2
syscall()
splbio()
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? but that brings me
back to the question about "well how do nfsd and nfsiod do it?"
Perhaps once an spl is initiated the process can not block?
the more I thought about this, the more my head ached :)
Mike, Terry, Matt, John?
thanks,
Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com
-- There are operating systems, and then there's FreeBSD.
-- http://www.freebsd.org/ 3.0-current
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?Pine.BSF.4.05.9812201621560.6331-100000>