On Mon, 15 Apr 1996 23:18:31 -0500, Larry 'Daffy' Daffner
<vizzie@airmail.net> said:
> I sent mail to the linux-kernel list about this once before and never
> got an answer. Am I missing something,
Yes...
> or is there some definite problems with the nfsiod code?
Nope. You're missing out some fundamental features of kernel mode
programming.
> I am assuming that from a process standpoint, the nfsiod code looks
> like a normal process with it's memory space mapped into kernel
> space,
Almost. Kernel threads don't have their own address space: "ps -amx"
will show all the kernel threads with zero memory. These threads are
indeed scheduled as user processes.
> and thus is subject to scheduling, and since there are multiple
> processes modifying the same kernel registers at potentially the same
> time, there are race conditions that need to be protected against,
> somehow. If I am wrong about those assumptions, please correct me.
The kernel threads execute permanently in kernel mode. Any task
running in kernel mode is *guaranteed* not to get rescheduled. The
kernel would be absolutely full of races otherwise. Vast portions of
the kernel code rely on the fact that they are the only process
executing (which incidentally is why it is hard to do SMP properly ---
we need to eliminate this restriction if we are to support multiple
processors executing kernel code concurrently).
A process in kernel mode, either a kernel thread or a process
executing a system call, can only ever be resceduled if:
1) It blocks, waiting for some external wakeup signal (the "sleep_on"
and "wait_on/wait_for" family of calls);
2) It calls schedule(); or
3) It tries to access some user memory and triggers a page fault.
Cheers,
Stephen.
-- Stephen Tweedie <sct@dcs.ed.ac.uk> Department of Computer Science, Edinburgh University, Scotland.