On Wed, Jun 06, 2001 at 11:51:58AM -0400, jmjonesat_private wrote: > Hrm. I was under the impression that code running in the kernel was > somewhat "protected" from race conditions. Perhaps I was mistaken.... > anybody? Kernel code is highly vulnerable to race conditions. The original Unix kernel philosophy allowed only one process to execute in the kernel at a time (sometimes, performing work on another process's behalf -- such as during disk IO, network IO, etc). However, allowing only process into the kernel makes multiprocessor machines much less efficient. Many processes would end up spending a lot of time blocking on entering the kernel. The Linux kernel first got SMP support in 2.0; however, this support was the inefficient sort. 2.2 added more fine-grained locks on critical code paths, but it was not until 2.4 that the locks were fine enough for SMP to be worthwhile for most users. (Solaris goes even further, with a kernel that has many preemption points throughout the kernel to improve real-time needs. It took a lot of work to bring Solaris to this point, however.) > Well, there's a lock_kernel() call that does something, and various other > mechanisms that could be used (hard lock, spin lock, logic lock), but you > have a very good point... and use of any of these may just mess me up > royally in the "more efficient" argument. Hard lock my machine, and I'll be rather upset. :) The best source of information on this topic that I have found is Uresh Vahalia's _Unix_Internals_. Actually, that is a rather good book in general. :) _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Wed Jun 06 2001 - 10:01:28 PDT