• Jeff Dike's avatar
    uml: iRQ stacks · c14b8494
    Jeff Dike authored
    Add a separate IRQ stack.  This differs from i386 in having the entire
    interrupt run on a separate stack rather than starting on the normal kernel
    stack and switching over once some preparation has been done.  The underlying
    mechanism, is of course, sigaltstack.
    
    Another difference is that interrupts that happen in userspace are handled on
    the normal kernel stack.  These cause a wait wakeup instead of a signal
    delivery so there is no point in trying to switch stacks for these.  There's
    no other stuff on the stack, so there is no extra stack consumption.
    
    This quirk makes it possible to have the entire interrupt run on a separate
    stack - process preemption (and calls to schedule()) happens on a normal
    kernel stack.  If we enable CONFIG_PREEMPT, this will need to be rethought.
    
    The IRQ stack for CPU 0 is declared in the same way as the initial kernel
    stack.  IRQ stacks for other CPUs will be allocated dynamically.
    
    An extra field was added to the thread_info structure.  When the active
    thread_info is copied to the IRQ stack, the real_thread field points back to
    the original stack.  This makes it easy to tell where to copy the thread_info
    struct back to when the interrupt is finished.  It also serves as a marker of
    a nested interrupt.  It is NULL for the first interrupt on the stack, and
    non-NULL for any nested interrupts.
    
    Care is taken to behave correctly if a second interrupt comes in when the
    thread_info structure is being set up or taken down.  I could just disable
    interrupts here, but I don't feel like giving up any of the performance gained
    by not flipping signals on and off.
    
    If an interrupt comes in during these critical periods, the handler can't run
    because it has no idea what shape the stack is in.  So, it sets a bit for its
    signal in a global mask and returns.  The outer handler will deal with this
    signal itself.
    
    Atomicity is had with xchg.  A nested interrupt that needs to bail out will
    xchg its signal mask into pending_mask and repeat in case yet another
    interrupt hit at the same time, until the mask stabilizes.
    
    The outermost interrupt will set up the thread_info and xchg a zero into
    pending_mask when it is done.  At this point, nested interrupts will look at
    ->real_thread and see that no setup needs to be done.  They can just continue
    normally.
    
    Similar care needs to be taken when exiting the outer handler.  If another
    interrupt comes in while it is copying the thread_info, it will drop a bit
    into pending_mask.  The outer handler will check this and if it is non-zero,
    will loop, set up the stack again, and handle the interrupt.
    Signed-off-by: default avatarJeff Dike <jdike@linux.intel.com>
    Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    c14b8494
process.c 4.78 KB