1. 08 5月, 2007 1 次提交
  2. 08 3月, 2007 1 次提交
  3. 04 11月, 2006 1 次提交
    • J
      [PATCH] uml: fix I/O hang · 53b17332
      Jeff Dike 提交于
      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: NJeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      53b17332
  4. 26 9月, 2006 2 次提交
  5. 11 7月, 2006 1 次提交
    • J
      [PATCH] uml: timer initialization cleanup · aceb3434
      Jeff Dike 提交于
      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: NJeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      aceb3434
  6. 19 1月, 2006 4 次提交
  7. 09 1月, 2006 1 次提交
  8. 06 5月, 2005 1 次提交
  9. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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