Messages in this thread | | | Date | Tue, 14 Mar 2000 18:57:50 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: [patch] preemptive kernel, preemptive-2.3.52-A7 |
| |
On Tue, 14 Mar 2000, Ingo Molnar wrote:
>but i just felt we want to make it IRQ-atomic as well (although this is >not strictly necessery now as IRQ contexts never change current->blah.) If >current->blah is modified from IRQ contexts as well then 'current->blah--' >is not IRQ-safe as it might get compiled into several instructions: > > movl blah, %eax > decl %eax > movl %eax, blah
All kernel places that does a preemot_on have also to do the preempt_off before returning to the lower layer so I think can consider the blah statatic at such point.
Also it make no sense to use preempt_on from an irq and the only case I can think of if is somebody does a copy_user in irq with a safe page locked down (so he known we can't fault on in and he can't use memcpy for sparc and others that have overlapping virtual addresses between user and kernel) but that is bad design anyway (and it's safe w.r.t. preempt_* for the above mentioned in the above paragraph).
So I don't think we need the non atomic incl/decl.
The compiler barrier() are necessary indeed.
Andrea
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |