On Wed, 6 Sep 2000, George Anzinger wrote:
>The times a kernel is not preemptable under this patch are:
>
>While handling interrupts.
>While doing "bottom half" processing.
>While holding a spinlock, writelock or readlock.
>
>At all other times the algorithm allows preemption.
So it can deadlock if somebody is doing:
while (test_and_set_bit(0, &something)) {
/* critical section */
mb();
clear_bit(0, &something);
}
The above is 100% correct code in all linux kernels out there. It
won't be correct anymore when you make the kernel preemtable with your
patch or also with the patch from ludovic.fernandez@sun.com of last month.
http://www.uwsg.iu.edu/hypermail/linux/kernel/0008.1/0842.html
The above construct it's discouraged of course when you can do the same
thing with a spinlock but some place is doing that.
I did a very fast grep I found several places that will deadlock with your
patch applied. (just grep for test_and_set_bit all over the kernel and
search for `while' in the output of the grep, this will give you the
obvious places, then we should as well check for all the other atomic
operations also the one that doesn't spin because the spin could happen
w/o an atomic operation... infact all spinning should be done w/o atomic
operations to avoid cacheline pingpong)
About the title "hard real-time fully preemptable Linux kernel prototype"
I'd say it's a little misleading given that the preemptable kernel have
nothing to do with hard real time.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:16 EST