1. 26 9月, 2006 1 次提交
  2. 15 7月, 2006 1 次提交
  3. 04 7月, 2006 6 次提交
    • I
      [PATCH] lockdep: kconfig · 4d9f34ad
      Ingo Molnar 提交于
      Offer the following lock validation options:
      
       CONFIG_PROVE_LOCKING
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4d9f34ad
    • I
      [PATCH] lockdep: core · fbb9ce95
      Ingo Molnar 提交于
      Do 'make oldconfig' and accept all the defaults for new config options -
      reboot into the kernel and if everything goes well it should boot up fine and
      you should have /proc/lockdep and /proc/lockdep_stats files.
      
      Typically if the lock validator finds some problem it will print out
      voluminous debug output that begins with "BUG: ..." and which syslog output
      can be used by kernel developers to figure out the precise locking scenario.
      
      What does the lock validator do?  It "observes" and maps all locking rules as
      they occur dynamically (as triggered by the kernel's natural use of spinlocks,
      rwlocks, mutexes and rwsems).  Whenever the lock validator subsystem detects a
      new locking scenario, it validates this new rule against the existing set of
      rules.  If this new rule is consistent with the existing set of rules then the
      new rule is added transparently and the kernel continues as normal.  If the
      new rule could create a deadlock scenario then this condition is printed out.
      
      When determining validity of locking, all possible "deadlock scenarios" are
      considered: assuming arbitrary number of CPUs, arbitrary irq context and task
      context constellations, running arbitrary combinations of all the existing
      locking scenarios.  In a typical system this means millions of separate
      scenarios.  This is why we call it a "locking correctness" validator - for all
      rules that are observed the lock validator proves it with mathematical
      certainty that a deadlock could not occur (assuming that the lock validator
      implementation itself is correct and its internal data structures are not
      corrupted by some other kernel subsystem).  [see more details and conditionals
      of this statement in include/linux/lockdep.h and
      Documentation/lockdep-design.txt]
      
      Furthermore, this "all possible scenarios" property of the validator also
      enables the finding of complex, highly unlikely multi-CPU multi-context races
      via single single-context rules, increasing the likelyhood of finding bugs
      drastically.  In practical terms: the lock validator already found a bug in
      the upstream kernel that could only occur on systems with 3 or more CPUs, and
      which needed 3 very unlikely code sequences to occur at once on the 3 CPUs.
      That bug was found and reported on a single-CPU system (!).  So in essence a
      race will be found "piecemail-wise", triggering all the necessary components
      for the race, without having to reproduce the race scenario itself!  In its
      short existence the lock validator found and reported many bugs before they
      actually caused a real deadlock.
      
      To further increase the efficiency of the validator, the mapping is not per
      "lock instance", but per "lock-class".  For example, all struct inode objects
      in the kernel have inode->inotify_mutex.  If there are 10,000 inodes cached,
      then there are 10,000 lock objects.  But ->inotify_mutex is a single "lock
      type", and all locking activities that occur against ->inotify_mutex are
      "unified" into this single lock-class.  The advantage of the lock-class
      approach is that all historical ->inotify_mutex uses are mapped into a single
      (and as narrow as possible) set of locking rules - regardless of how many
      different tasks or inode structures it took to build this set of rules.  The
      set of rules persist during the lifetime of the kernel.
      
      To see the rough magnitude of checking that the lock validator does, here's a
      portion of /proc/lockdep_stats, fresh after bootup:
      
       lock-classes:                            694 [max: 2048]
       direct dependencies:                  1598 [max: 8192]
       indirect dependencies:               17896
       all direct dependencies:             16206
       dependency chains:                    1910 [max: 8192]
       in-hardirq chains:                      17
       in-softirq chains:                     105
       in-process chains:                    1065
       stack-trace entries:                 38761 [max: 131072]
       combined max dependencies:         2033928
       hardirq-safe locks:                     24
       hardirq-unsafe locks:                  176
       softirq-safe locks:                     53
       softirq-unsafe locks:                  137
       irq-safe locks:                         59
       irq-unsafe locks:                      176
      
      The lock validator has observed 1598 actual single-thread locking patterns,
      and has validated all possible 2033928 distinct locking scenarios.
      
      More details about the design of the lock validator can be found in
      Documentation/lockdep-design.txt, which can also found at:
      
         http://redhat.com/~mingo/lockdep-patches/lockdep-design.txt
      
      [bunk@stusta.de: cleanups]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fbb9ce95
    • I
      [PATCH] lockdep: locking API self tests · cae2ed9a
      Ingo Molnar 提交于
      Introduce DEBUG_LOCKING_API_SELFTESTS, which uses the generic lock debugging
      code's silent-failure feature to run a matrix of testcases.  There are 210
      testcases currently:
      
        +-----------------------
        | Locking API testsuite:
        +------------------------------+------+------+------+------+------+------+
                                       | spin |wlock |rlock |mutex | wsem | rsem |
        -------------------------------+------+------+------+------+------+------+
                           A-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                       A-B-B-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                   A-B-B-C-C-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                   A-B-C-A-B-C deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
               A-B-B-C-C-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
               A-B-C-D-B-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
               A-B-C-D-B-C-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                          double unlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                       bad unlock order:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
        --------------------------------------+------+------+------+------+------+
                    recursive read-lock:             |  ok  |             |  ok  |
        --------------------------------------+------+------+------+------+------+
                      non-nested unlock:  ok  |  ok  |  ok  |  ok  |
        --------------------------------------+------+------+------+
           hard-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
           soft-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
           hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
           soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
             sirq-safe-A => hirqs-on/12:  ok  |  ok  |  ok  |
             sirq-safe-A => hirqs-on/21:  ok  |  ok  |  ok  |
               hard-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
               soft-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
               hard-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
               soft-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
          hard-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
          soft-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
            hard-irq lock-inversion/123:  ok  |  ok  |  ok  |
            soft-irq lock-inversion/123:  ok  |  ok  |  ok  |
            hard-irq lock-inversion/132:  ok  |  ok  |  ok  |
            soft-irq lock-inversion/132:  ok  |  ok  |  ok  |
            hard-irq lock-inversion/213:  ok  |  ok  |  ok  |
            soft-irq lock-inversion/213:  ok  |  ok  |  ok  |
            hard-irq lock-inversion/231:  ok  |  ok  |  ok  |
            soft-irq lock-inversion/231:  ok  |  ok  |  ok  |
            hard-irq lock-inversion/312:  ok  |  ok  |  ok  |
            soft-irq lock-inversion/312:  ok  |  ok  |  ok  |
            hard-irq lock-inversion/321:  ok  |  ok  |  ok  |
            soft-irq lock-inversion/321:  ok  |  ok  |  ok  |
            hard-irq read-recursion/123:  ok  |
            soft-irq read-recursion/123:  ok  |
            hard-irq read-recursion/132:  ok  |
            soft-irq read-recursion/132:  ok  |
            hard-irq read-recursion/213:  ok  |
            soft-irq read-recursion/213:  ok  |
            hard-irq read-recursion/231:  ok  |
            soft-irq read-recursion/231:  ok  |
            hard-irq read-recursion/312:  ok  |
            soft-irq read-recursion/312:  ok  |
            hard-irq read-recursion/321:  ok  |
            soft-irq read-recursion/321:  ok  |
        --------------------------------+-----+----------------
        Good, all 210 testcases passed! |
        --------------------------------+
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cae2ed9a
    • H
      [PATCH] lockdep: s390 CONFIG_FRAME_POINTER support · cbbd1fa7
      Heiko Carstens 提交于
      CONFIG_FRAME_POINTER support for s390.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cbbd1fa7
    • I
      [PATCH] lockdep: stacktrace subsystem, core · 8637c099
      Ingo Molnar 提交于
      Framework to generate and save stacktraces quickly, without printing anything
      to the console.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8637c099
    • I
      [PATCH] lockdep: remove mutex deadlock checking code · fb7e4241
      Ingo Molnar 提交于
      With the lock validator we detect mutex deadlocks (and more), the mutex
      deadlock checking code is both redundant and slower.  So remove it.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fb7e4241
  4. 29 6月, 2006 1 次提交
  5. 28 6月, 2006 3 次提交
  6. 27 6月, 2006 3 次提交
  7. 13 5月, 2006 1 次提交
  8. 20 4月, 2006 1 次提交
    • T
      [PATCH] Kconfig.debug: Set DEBUG_MUTEX to off by default · cca57c5b
      Tim Chen 提交于
      DEBUG_MUTEX flag is on by default in current kernel configuration.
      
      During performance testing, we saw mutex debug functions like
      mutex_debug_check_no_locks_freed (called by kfree()) is expensive as it
      goes through a global list of memory areas with mutex lock and do the
      checking.  For benchmarks such as Volanomark and Hackbench, we have seen
      more than 40% drop in performance on some platforms.  We suggest to set
      DEBUG_MUTEX off by default.  Or at least do that later when we feel that
      the mutex changes in the current code have stabilized.
      Signed-off-by: NTim Chen <tim.c.chen@intel.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cca57c5b
  9. 31 3月, 2006 1 次提交
  10. 27 3月, 2006 1 次提交
  11. 26 3月, 2006 3 次提交
    • A
      [PATCH] x86_64: Don't enable CONFIG_UNWIND_INFO by default for DEBUG_KERNEL · 6a0f03e0
      Andi Kleen 提交于
      DEBUG_KERNEL is often enabled just for sysrq, but this doesn't
      mean the user wants more heavyweight debugging information.
      
      Cc: jbeulich@novell.com
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6a0f03e0
    • A
      [PATCH] kconfig: clarify memory debug options · 4a2f0acf
      Andrew Morton 提交于
      The Kconfig text for CONFIG_DEBUG_SLAB and CONFIG_DEBUG_PAGEALLOC have always
      seemed a bit confusing.  Change them to:
      
      CONFIG_DEBUG_SLAB: "Debug slab memory allocations"
      CONFIG_DEBUG_PAGEALLOC: "Debug page memory allocations"
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4a2f0acf
    • A
      [PATCH] slab: implement /proc/slab_allocators · 871751e2
      Al Viro 提交于
      Implement /proc/slab_allocators.   It produces output like:
      
      idr_layer_cache: 80 idr_pre_get+0x33/0x4e
      buffer_head: 2555 alloc_buffer_head+0x20/0x75
      mm_struct: 9 mm_alloc+0x1e/0x42
      mm_struct: 20 dup_mm+0x36/0x370
      vm_area_struct: 384 dup_mm+0x18f/0x370
      vm_area_struct: 151 do_mmap_pgoff+0x2e0/0x7c3
      vm_area_struct: 1 split_vma+0x5a/0x10e
      vm_area_struct: 11 do_brk+0x206/0x2e2
      vm_area_struct: 2 copy_vma+0xda/0x142
      vm_area_struct: 9 setup_arg_pages+0x99/0x214
      fs_cache: 8 copy_fs_struct+0x21/0x133
      fs_cache: 29 copy_process+0xf38/0x10e3
      files_cache: 30 alloc_files+0x1b/0xcf
      signal_cache: 81 copy_process+0xbaa/0x10e3
      sighand_cache: 77 copy_process+0xe65/0x10e3
      sighand_cache: 1 de_thread+0x4d/0x5f8
      anon_vma: 241 anon_vma_prepare+0xd9/0xf3
      size-2048: 1 add_sect_attrs+0x5f/0x145
      size-2048: 2 journal_init_revoke+0x99/0x302
      size-2048: 2 journal_init_revoke+0x137/0x302
      size-2048: 2 journal_init_inode+0xf9/0x1c4
      
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Alexander Nyberg <alexn@telia.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Christoph Lameter <clameter@engr.sgi.com>
      Cc: Ravikiran Thirumalai <kiran@scalex86.org>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      DESC
      slab-leaks3-locking-fix
      EDESC
      From: Andrew Morton <akpm@osdl.org>
      
      Update for slab-remove-cachep-spinlock.patch
      
      Cc: Al Viro <viro@ftp.linux.org.uk>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: Alexander Nyberg <alexn@telia.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Christoph Lameter <clameter@engr.sgi.com>
      Cc: Ravikiran Thirumalai <kiran@scalex86.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      871751e2
  12. 24 3月, 2006 1 次提交
    • J
      [PATCH] CONFIG_UNWIND_INFO · 604bf5a2
      Jan Beulich 提交于
      As a foundation for reliable stack unwinding, this adds a config option
      (available to all architectures except IA64 and those where the module
      loader might have problems with the resulting relocations) to enable the
      generation of frame unwind information.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Paul Mundt <lethal@linux-sh.org>,
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      604bf5a2
  13. 15 1月, 2006 1 次提交
  14. 11 1月, 2006 1 次提交
  15. 10 1月, 2006 1 次提交
  16. 09 1月, 2006 1 次提交
  17. 07 1月, 2006 2 次提交
  18. 31 10月, 2005 3 次提交
  19. 13 9月, 2005 1 次提交
  20. 08 9月, 2005 1 次提交
  21. 30 7月, 2005 1 次提交
  22. 29 5月, 2005 1 次提交
  23. 01 5月, 2005 1 次提交
  24. 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