> 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
Yes.
> to compute current. So either outlaw it (add a check to current for a few
If I unserstood well Ingo said that some kernel code send a signal to the
current process inside the interrupt handler (I can imagine during C^c) so
we should change current-> with irq_current-> inside the interrupt handler
and catch the start of the old stack from irq_current (this sound simple).
> releases to catch it), or alternatively give the interrupts a special
^^^^^^^^^^^^^^^^^^^^
Yes to catch the old current during the irq_current migration.
> task_structure that stays static - an "interrupt thread". This thread is
> not scheduled, it just exists to have a current during interrupt processing.
Hmm changing current to irq_current inside the irq_handlers sound very
simpler and cleaner to me.
> > 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)
Good idea! This sound pretty trivial doable too.
Before starting the implementation (this night I think) I would like to
hear from The Kernel Hackers if I am wasting time ;-).
Andrea[s] Arcangeli
-
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