lkml.org 
[lkml]   [1998]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Strange interrupt behaviour
On Thu, Jul 16, 1998 at 09:10:34AM +0200, Andrea Arcangeli wrote:
> On Thu, 16 Jul 1998, Andi Kleen wrote:
>
> >> And how do you handle a per CPU stack?
> >
> >How? (I'm not sure if I follow you here)
> >
> >Just use smp_processor_id() to select the right stack, just like
> >do_IRQ already does to update the per-CPU interrupt statistics.
>
> OK. Just implemented. To make my patch safe now I only need to align the
> per interrupt stack with the memory page and memcpy from current to
> irq_stack the task struct everytime there is an interrupt (I also need to
> enlarge the per interrupt stack to 8kbyte due get_current()
> implementation). Probably the memcpy will cause an high overhead... but
> just to try...

Right. Currently in the usual paths current is only used to compute
smp_processor_id() early in do_IRQ. This is no problem because the old
stack is probably still there. For later interrupts it makes not much sense
to compute current. So either outlaw it (add a check to current for a few
releases to catch it), or alternatively give the interrupts a special
task_structure that stays static - an "interrupt thread". This thread is
not scheduled, it just exists to have a current during interrupt processing.

> And for the race I think that we could fix it.

You have to check if you're already running on the interrupt stack, and
increment a counter if yes (otherwise you switch back to the wrong stack)

-Andi

-
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.altern.org/andrebalsa/doc/lkml-faq.html

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