Hello Manfred, > The only difference between you patch and now 2.6.23-rc4-rt1 is that now a > raw_ spinlock is used. So i think when using your patch on 2.6.21.5-rt20, > because a customer has this kernel running, i have there also to use a > raw_spinlock ?
The same patch applies to older kernels. Besides, I use this patch for a while now on 2.6.21 and 2.6.22, but with an interrupt lock instead of a spinlock. A raw_spinlock is better because it is safe in SMP also, so Ingo has the proper implementation in his patch, which you should follow. (Probably this is technically the best possible solution, given the limited amount of atomic-instructions on ARM-v4/v5) So, A normal (non-raw) spinlock should NOT be used here, because that does would be converted to a rt-mutex, which is preemptible. If this code is preemptible, it could be preempted by another user space thread which could, in theory, modify the same piece of memory, and thus causing a race condition. Notice that there have been raised questions about the interrupt lock while accessing user space memory in this code, it is considered as not-safe. AFAIK the only situation where it is not-safe, is the case where the memory is not available in RAM, but e.g. somewhere in a swap space. If the memory has to be paged in, probably interrupts are needed. In my system things like this will never happen... Maybe Ingo, Thomas or someone else can acknowledge (or trash) my opinion here? Kind Regards, Remy Bohmer - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
