Messages in this thread | | | Date | Thu, 16 Jul 1998 12:16:17 +0200 | From | Andi Kleen <> | Subject | Re: 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
| |