lkml.org 
[lkml]   [2000]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.216 / U:0.560 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site