1. 05 Feb, 2008 3 commits
  2. 16 Oct, 2007 7 commits
  3. 19 Sep, 2007 1 commit
    • Jeff Dike's avatar
      uml: fix irqstack crash · 508a9274
      Jeff Dike authored
      
      
      This patch fixes a crash caused by an interrupt coming in when an IRQ stack
      is being torn down.  When this happens, handle_signal will loop, setting up
      the IRQ stack again because the tearing down had finished, and handling
      whatever signals had come in.
      
      However, to_irq_stack returns a mask of pending signals to be handled, plus
      bit zero is set if the IRQ stack was already active, and thus shouldn't be
      torn down.  This causes a problem because when handle_signal goes around
      the loop, sig will be zero, and to_irq_stack will duly set bit zero in the
      returned mask, faking handle_signal into believing that it shouldn't tear
      down the IRQ stack and return thread_info pointers back to their original
      values.
      
      This will eventually cause a crash, as the IRQ stack thread_info will
      continue pointing to the original task_struct and an interrupt will look
      into it after it has been freed.
      
      The fix is to stop passing a signal number into to_irq_stack.  Rather, the
      pending signals mask is initialized beforehand with the bit for sig already
      set.  References to sig in to_irq_stack can be replaced with references to
      the mask.
      
      [akpm@linux-foundation.org: use UL]
      Signed-off-by: default avatarJeff Dike <jdike@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      508a9274
  4. 11 May, 2007 2 commits
    • 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
    • Jeff Dike's avatar
      uml: tidy IRQ code · 2ea5bc5e
      Jeff Dike authored
      
      
      Some tidying of the irq code before introducing irq stacks.  Mostly
      style fixes, but the timer handler calls the timer code directly
      rather than going through the generic sig_handler_common_skas.
      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>
      2ea5bc5e
  5. 07 May, 2007 1 commit
  6. 08 Mar, 2007 1 commit
  7. 03 Nov, 2006 1 commit
    • Jeff Dike's avatar
      [PATCH] uml: fix I/O hang · 53b17332
      Jeff Dike authored
      
      
      Fix a UML hang in which everything would just stop until some I/O happened
      - a ping, someone whacking the keyboard - at which point everything would
      start up again as though nothing had happened.
      
      The cause was gcc reordering some code which absolutely needed to be
      executed in the order in the source.  When unblock_signals switches signals
      from off to on, it needs to see if any interrupts had happened in the
      critical section.  The interrupt handlers check signals_enabled - if it is
      zero, then the handler adds a bit to the "pending" bitmask and returns.
      unblock_signals checks this mask to see if any signals need to be
      delivered.
      
      The crucial part is this:
      	signals_enabled = 1;
      	save_pending = pending;
      	if(save_pending == 0)
      		return;
      	pending = 0;
      
      In order to avoid an interrupt arriving between reading pending and setting
      it to zero, in which case, the record of the interrupt would be erased,
      signals are enabled.
      
      What happened was that gcc reordered this so that 'save_pending = pending'
      came before 'signals_enabled = 1', creating a one-instruction window within
      which an interrupt could arrive, set its bit in pending, and have it be
      immediately erased.
      
      When the I/O workload is purely disk-based, the loss of a block device
      interrupt stops the entire I/O system because the next block request will
      wait for the current one to finish.  Thus the system hangs until something
      else causes some I/O to arrive, such as a network packet or console input.
      
      The fix to this particular problem is a memory barrier between enabling
      signals and reading the pending signal mask.  An xchg would also probably
      work.
      
      Looking over this code for similar problems led me to do a few more
      things:
      
      - make signals_enabled and pending volatile so that they don't get cached
        in registers
      
      - add an mb() to the return paths of block_signals and unblock_signals so
        that the modification of signals_enabled doesn't get shuffled into the
        caller in the event that these are inlined in the future.
      Signed-off-by: default avatarJeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      53b17332
  8. 26 Sep, 2006 2 commits
  9. 10 Jul, 2006 1 commit
    • Jeff Dike's avatar
      [PATCH] uml: timer initialization cleanup · aceb3434
      Jeff Dike authored
      
      
      This cleans up the mess that is the timer initialization.  There used to be
      two timer handlers - one that basically ran during delay loop calibration and
      one that handled the timer afterwards.  There were also two sets of timer
      initialization code - one that starts in user code and calls into the kernel
      side of the house, and one that starts in kernel code and calls user code.
      
      This eliminates one timer handler and consolidates the two sets of
      initialization code.
      
      [akpm@osdl.org: use new INTF_ flags]
      Signed-off-by: default avatarJeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      aceb3434
  10. 18 Jan, 2006 4 commits
  11. 08 Jan, 2006 1 commit
  12. 05 May, 2005 1 commit
  13. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4