Messages in this thread | | | Date | Wed, 17 Apr 1996 00:50:57 +0100 | From | "Stephen C. Tweedie" <> | Subject | Re: nfsiod issues? |
| |
Hi,
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.
| |