1. 12 1月, 2011 1 次提交
    • D
      xfs: prevent NMI timeouts in cmn_err · 73efe4a4
      Dave Chinner 提交于
      We currently have a global error message buffer in cmn_err that is
      protected by a spin lock that disables interrupts.  Recently there
      have been reports of NMI timeouts occurring when the console is
      being flooded by SCSI error reports due to cmn_err() getting stuck
      trying to print to the console while holding this lock (i.e. with
      interrupts disabled). The NMI watchdog is seeing this CPU as
      non-responding and so is triggering a panic.  While the trigger for
      the reported case is SCSI errors, pretty much anything that spams
      the kernel log could cause this to occur.
      
      Realistically the only reason that we have the intemediate message
      buffer is to prepend the correct kernel log level prefix to the log
      message. The only reason we have the lock is to protect the global
      message buffer and the only reason the message buffer is global is
      to keep it off the stack. Hence if we can avoid needing a global
      message buffer we avoid needing the lock, and we can do this with a
      small amount of cleanup and some preprocessor tricks:
      
      	1. clean up xfs_cmn_err() panic mask functionality to avoid
      	   needing debug code in xfs_cmn_err()
      	2. remove the couple of "!" message prefixes that still exist that
      	   the existing cmn_err() code steps over.
      	3. redefine CE_* levels directly to KERN_*
      	4. redefine cmn_err() and friends to use printk() directly
      	   via variable argument length macros.
      
      By doing this, we can completely remove the cmn_err() code and the
      lock that is causing the problems, and rely solely on printk()
      serialisation to ensure that we don't get garbled messages.
      
      A series of followup patches is really needed to clean up all the
      cmn_err() calls and related messages properly, but that results in a
      series that is not easily back portable to enterprise kernels. Hence
      this initial fix is only to address the direct problem in the lowest
      impact way possible.
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAlex Elder <aelder@sgi.com>
      73efe4a4
  2. 01 12月, 2010 1 次提交
    • D
      xfs: only run xfs_error_test if error injection is active · c76febef
      Dave Chinner 提交于
      Recent tests writing lots of small files showed the flusher thread
      being CPU bound and taking a long time to do allocations on a debug
      kernel. perf showed this as the prime reason:
      
                   samples  pcnt function                    DSO
                   _______ _____ ___________________________ _________________
      
                 224648.00 36.8% xfs_error_test              [kernel.kallsyms]
                  86045.00 14.1% xfs_btree_check_sblock      [kernel.kallsyms]
                  39778.00  6.5% prandom32                   [kernel.kallsyms]
                  37436.00  6.1% xfs_btree_increment         [kernel.kallsyms]
                  29278.00  4.8% xfs_btree_get_rec           [kernel.kallsyms]
                  27717.00  4.5% random32                    [kernel.kallsyms]
      
      Walking btree blocks during allocation checking them requires each
      block (a cache hit, so no I/O) call xfs_error_test(), which then
      does a random32() call as the first operation.  IOWs, ~50% of the
      CPU is being consumed just testing whether we need to inject an
      error, even though error injection is not active.
      
      Kill this overhead when error injection is not active by adding a
      global counter of active error traps and only calling into
      xfs_error_test when fault injection is active.
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      c76febef
  3. 19 5月, 2010 1 次提交
  4. 22 12月, 2008 1 次提交
  5. 13 8月, 2008 1 次提交
  6. 28 7月, 2008 1 次提交
    • C
      [XFS] streamline init/exit path · 9f8868ff
      Christoph Hellwig 提交于
      Currently the xfs module init/exit code is a mess. It's farmed out over a
      lot of function with very little error checking. This patch makes sure we
      propagate all initialization failures properly and clean up after them.
      Various runtime initializations are replaced with compile-time
      initializations where possible to make this easier. The exit path is
      similarly consolidated.
      
      There's now split out function to create/destroy the kmem zones and
      alloc/free the trace buffers. I've also changed the ktrace allocations to
      KM_MAYFAIL and handled errors resulting from that.
      
      And yes, we really should replace the XFS_*_TRACE ifdefs with a single
      XFS_TRACE..
      
      SGI-PV: 976035
      
      SGI-Modid: xfs-linux-melb:xfs-kern:31354a
      Signed-off-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NNiv Sardi <xaiki@sgi.com>
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      9f8868ff
  7. 07 2月, 2008 1 次提交
  8. 16 10月, 2007 1 次提交
  9. 10 2月, 2007 2 次提交
  10. 28 9月, 2006 2 次提交
  11. 31 3月, 2006 1 次提交
  12. 12 1月, 2006 1 次提交
  13. 02 11月, 2005 2 次提交
  14. 21 6月, 2005 1 次提交
  15. 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