1. 25 5月, 2011 2 次提交
  2. 20 5月, 2011 1 次提交
  3. 19 5月, 2011 1 次提交
  4. 06 5月, 2011 2 次提交
  5. 28 4月, 2011 1 次提交
  6. 10 4月, 2011 1 次提交
  7. 05 4月, 2011 1 次提交
  8. 23 3月, 2011 3 次提交
  9. 21 3月, 2011 1 次提交
  10. 05 3月, 2011 1 次提交
    • A
      BKL: That's all, folks · 4ba8216c
      Arnd Bergmann 提交于
      This removes the implementation of the big kernel lock,
      at last. A lot of people have worked on this in the
      past, I so the credit for this patch should be with
      everyone who participated in the hunt.
      
      The names on the Cc list are the people that were the
      most active in this, according to the recorded git
      history, in alphabetical order.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NAlan Cox <alan@linux.intel.com>
      Cc: Alessio Igor Bogani <abogani@texware.it>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andrew Hendry <andrew.hendry@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Hans Verkuil <hverkuil@xs4all.nl>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: Jan Blunck <jblunck@infradead.org>
      Cc: John Kacur <jkacur@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: Oliver Neukum <oliver@neukum.org>
      Cc: Paul Menage <menage@google.com>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Trond Myklebust <Trond.Myklebust@netapp.com>
      4ba8216c
  11. 24 2月, 2011 1 次提交
  12. 08 2月, 2011 1 次提交
  13. 21 1月, 2011 1 次提交
    • D
      kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT · 6a108a14
      David Rientjes 提交于
      The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
      is used to configure any non-standard kernel with a much larger scope than
      only small devices.
      
      This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
      references to the option throughout the kernel.  A new CONFIG_EMBEDDED
      option is added that automatically selects CONFIG_EXPERT when enabled and
      can be used in the future to isolate options that should only be
      considered for embedded systems (RISC architectures, SLOB, etc).
      
      Calling the option "EXPERT" more accurately represents its intention: only
      expert users who understand the impact of the configuration changes they
      are making should enable it.
      Reviewed-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NDavid Woodhouse <david.woodhouse@intel.com>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: Greg KH <gregkh@suse.de>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Robin Holt <holt@sgi.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6a108a14
  14. 23 12月, 2010 1 次提交
    • D
      x86, nmi_watchdog: Remove ARCH_HAS_NMI_WATCHDOG and rely on CONFIG_HARDLOCKUP_DETECTOR · 4a7863cc
      Don Zickus 提交于
      The x86 arch has shifted its use of the nmi_watchdog from a
      local implementation to the global one provide by
      kernel/watchdog.c.  This shift has caused a whole bunch of
      compile problems under different config options.  I attempt to
      simplify things with the patch below.
      
      In order to simplify things, I had to come to terms with the
      meaning of two terms ARCH_HAS_NMI_WATCHDOG and
      CONFIG_HARDLOCKUP_DETECTOR.  Basically they mean the same thing,
      the former on a local level and the latter on a global level.
      
      With the old x86 nmi watchdog gone, there is no need to rely on
      defining the ARCH_HAS_NMI_WATCHDOG variable because it doesn't
      make sense any more.  x86 will now use the global
      implementation.
      
      The changes below do a few things.  First it changes the few
      places that relied on ARCH_HAS_NMI_WATCHDOG to use
      CONFIG_X86_LOCAL_APIC (the former was an alias for the latter
      anyway, so nothing unusual here).  Those pieces of code were
      relying more on local apic functionality the nmi watchdog
      functionality, so the change should make sense.
      
      Second, I removed the x86 implementation of
      touch_nmi_watchdog().  It isn't need now, instead x86 will rely
      on kernel/watchdog.c's implementation.
      
      Third, I removed the #define ARCH_HAS_NMI_WATCHDOG itself from
      x86.  And tweaked the include/linux/nmi.h file to tell users to
      look for an externally defined touch_nmi_watchdog in the case of
      ARCH_HAS_NMI_WATCHDOG _or_ CONFIG_HARDLOCKUP_DETECTOR. This
      changes removes some of the ugliness in that file.
      
      Finally, I added a Kconfig dependency for
      CONFIG_HARDLOCKUP_DETECTOR that said you can't have
      ARCH_HAS_NMI_WATCHDOG _and_ CONFIG_HARDLOCKUP_DETECTOR.  You can
      only have one nmi_watchdog.
      
      Tested with
      ARCH=i386: allnoconfig, defconfig, allyesconfig, (various broken
      configs) ARCH=x86_64: allnoconfig, defconfig, allyesconfig,
      (various broken configs)
      
      Hopefully, after this patch I won't get any more compile broken
      emails. :-)
      
      v3:
        changed a couple of 'linux/nmi.h' -> 'asm/nmi.h' to pick-up correct function
        prototypes when CONFIG_HARDLOCKUP_DETECTOR is not set.
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: fweisbec@gmail.com
      LKML-Reference: <1293044403-14117-1-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4a7863cc
  15. 27 10月, 2010 2 次提交
    • A
      lib/Kconfig.debug: add list_sort debugging switch · 6d411e6c
      Artem Bityutskiy 提交于
      While hunting a non-existing bug in 'list_sort()', I've improved the
      'list_sort_test()' function which tests the 'list_sort()' library call.
      Although at the end I found a bug in my code, but not in 'list_sort()', I
      think my clean-ups and improvements are worth merging because they make
      the test function better.
      
      This patch:
      
      Make the self-tests selectable via Kconfig rather than by manual enabling
      of DEBUG_LIST_SORT.
      Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Cc: Don Mullis <don.mullis@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6d411e6c
    • T
      percpu_counter: add debugobj support · e2852ae8
      Tejun Heo 提交于
      All percpu counters are linked to a global list on initialization and
      removed from it on destruction.  The list is walked during CPU up/down.
      If a percpu counter is freed without being properly destroyed, the system
      will oops only on the next CPU up/down making it pretty nasty to track
      down.  This patch adds debugobj support for percpu counters so that such
      problems can be found easily.
      
      As percpu counters don't make sense on stack and can't be statically
      initialized, debugobj support is pretty simple.  It's initialized and
      activated on counter initialization, and deactivatd and destroyed on
      counter destruction.  With this patch applied, the bug fixed by commit
      602586a8 (shmem: put_super must
      percpu_counter_destroy) triggers the following warning on tmpfs unmount
      and the system won't oops on the next cpu up/down operation.
      
       ------------[ cut here ]------------
       WARNING: at lib/debugobjects.c:259 debug_print_object+0x5c/0x70()
       Hardware name: Bochs
       ODEBUG: free active (active state 0) object type: percpu_counter
       Modules linked in:
       Pid: 3999, comm: umount Not tainted 2.6.36-rc2-work+ #5
       Call Trace:
        [<ffffffff81083f7f>] warn_slowpath_common+0x7f/0xc0
        [<ffffffff81084076>] warn_slowpath_fmt+0x46/0x50
        [<ffffffff813b45cc>] debug_print_object+0x5c/0x70
        [<ffffffff813b50e5>] debug_check_no_obj_freed+0x125/0x210
        [<ffffffff811577d3>] kfree+0xb3/0x2f0
        [<ffffffff81132edd>] shmem_put_super+0x1d/0x30
        [<ffffffff81162e96>] generic_shutdown_super+0x56/0xe0
        [<ffffffff81162f86>] kill_anon_super+0x16/0x60
        [<ffffffff81162ff7>] kill_litter_super+0x27/0x30
        [<ffffffff81163295>] deactivate_locked_super+0x45/0x60
        [<ffffffff81163cfa>] deactivate_super+0x4a/0x70
        [<ffffffff8117d446>] mntput_no_expire+0x86/0xe0
        [<ffffffff8117df7f>] sys_umount+0x6f/0x360
        [<ffffffff8103f01b>] system_call_fastpath+0x16/0x1b
       ---[ end trace cce2a341ba3611a7 ]---
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: Thomas Gleixner <tglxlinutronix.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e2852ae8
  16. 21 10月, 2010 1 次提交
    • A
      BKL: introduce CONFIG_BKL. · 6de5bd12
      Arnd Bergmann 提交于
      With all the patches we have queued in the BKL removal tree, only a
      few dozen modules are left that actually rely on the BKL, and even
      there are lots of low-hanging fruit. We need to decide what to do
      about them, this patch illustrates one of the options:
      
      Every user of the BKL is marked as 'depends on BKL' in Kconfig,
      and the CONFIG_BKL becomes a user-visible option. If it gets
      disabled, no BKL using module can be built any more and the BKL
      code itself is compiled out.
      
      The one exception is file locking, which is practically always
      enabled and does a 'select BKL' instead. This effectively forces
      CONFIG_BKL to be enabled until we have solved the fs/lockd
      mess and can apply the patch that removes the BKL from fs/locks.c.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      6de5bd12
  17. 15 10月, 2010 1 次提交
  18. 08 10月, 2010 1 次提交
    • D
      move async raid6 test to lib/Kconfig.debug · 400fb7f6
      Dan Williams 提交于
      The prompt for "Self test for hardware accelerated raid6 recovery" does not
      belong in the top level configuration menu.  All the options in
      crypto/async_tx/Kconfig are selected and do not depend on CRYPTO.
      Kconfig.debug seems like a reasonable fit.
      
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: David Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      400fb7f6
  19. 06 10月, 2010 1 次提交
  20. 24 9月, 2010 1 次提交
  21. 01 9月, 2010 1 次提交
    • S
      tracing/lockdep: Fix dependency of TRACE_IRQFLAGS · 46b93b74
      Steven Rostedt 提交于
      When CONFIG_IRQSOFF_TRACER is set and CONFIG_PROVE_LOCKING is not, we
      get the following error:
      
      $  make oldconfig
      scripts/kconfig/conf --oldconfig arch/x86/Kconfig
      warning: (IRQSOFF_TRACER && TRACING_SUPPORT && FTRACE && TRACE_IRQFLAGS_SUPPORT && !ARCH_USES_GETTIMEOFFSET) selects TRACE_IRQFLAGS which has unmet direct dependencies (DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && PROVE_LOCKING)
      warning: (IRQSOFF_TRACER && TRACING_SUPPORT && FTRACE && TRACE_IRQFLAGS_SUPPORT && !ARCH_USES_GETTIMEOFFSET) selects TRACE_IRQFLAGS which has unmet direct dependencies (DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && PROVE_LOCKING)
      
      This is because IRQSOFF_TRACER selects TRACE_IRQFLAGS but TRACE_IRQFLAGS
      has PROVE_LOCKING as a dependency. This code is incorrect, and
      this patch changes the TRACE_IRQFLAGS to be just a simple bool that
      does not depend or select anything. Instead both IRQSOFF_TRACER and
      PROVE_LOCKING select it.
      Reported-by: NRichard Kennedy <richard@rsk.demon.co.uk>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      46b93b74
  22. 20 8月, 2010 3 次提交
    • P
      rcu: Allow RCU CPU stall warnings to be off at boot, but manually enablable · 910b1b7e
      Paul E. McKenney 提交于
      Currently, if RCU CPU stall warnings are enabled, they are enabled
      immediately upon boot.  They can be manually disabled via /sys (and
      also re-enabled via /sys), and are automatically disabled upon panic.
      However, some users need RCU CPU stalls to be disabled at boot time,
      but to be enabled without rebuilding/rebooting.  For example, someone
      running a real-time application in production might not want the
      additional latency of RCU CPU stall detection in normal operation, but
      might need to enable it at any point for fault isolation purposes.
      
      This commit therefore provides a new CONFIG_RCU_CPU_STALL_DETECTOR_RUNNABLE
      kernel configuration parameter that maintains the current behavior
      (enable at boot) by default, but allows a kernel to be configured
      with RCU CPU stall detection built into the kernel, but disabled at
      boot time.
      Requested-by: NClark Williams <williams@redhat.com>
      Requested-by: NJohn Kacur <jkacur@redhat.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      910b1b7e
    • P
      rcu: make CPU stall warning timeout configurable · b163760e
      Paul E. McKenney 提交于
      Also set the default to 60 seconds, up from the previous hard-coded timeout
      of 10 seconds.  This allows people who care to set short timeouts, while
      avoiding people with unusual configurations (make randconfig!!!) from being
      bothered with spurious CPU stall warnings.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
      b163760e
    • P
      rcu: define __rcu address space modifier for sparse · ca5ecddf
      Paul E. McKenney 提交于
      This commit provides definitions for the __rcu annotation defined earlier.
      This annotation permits sparse to check for correct use of RCU-protected
      pointers.  If a pointer that is annotated with __rcu is accessed
      directly (as opposed to via rcu_dereference(), rcu_assign_pointer(),
      or one of their variants), sparse can be made to complain.  To enable
      such complaints, use the new default-disabled CONFIG_SPARSE_RCU_POINTER
      kernel configuration option.  Please note that these sparse complaints are
      intended to be a debugging aid, -not- a code-style-enforcement mechanism.
      
      There are special rcu_dereference_protected() and rcu_access_pointer()
      accessors for use when RCU read-side protection is not required, for
      example, when no other CPU has access to the data structure in question
      or while the current CPU hold the update-side lock.
      
      This patch also updates a number of docbook comments that were showing
      their age.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Christopher Li <sparse@chrisli.org>
      Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
      ca5ecddf
  23. 17 8月, 2010 1 次提交
    • R
      latencytop: Fix kconfig dependency warnings · 625fdcaa
      Randy Dunlap 提交于
      warning: (LATENCYTOP && HAVE_LATENCYTOP_SUPPORT) selects
      SCHED_DEBUG which has unmet direct dependencies (DEBUG_KERNEL &&
      PROC_FS) warning: (LATENCYTOP && HAVE_LATENCYTOP_SUPPORT) selects
      SCHEDSTATS which has unmet direct dependencies (DEBUG_KERNEL && PROC_FS)
      
      Add depends on STACKTRACE_SUPPORT for 'select STACKTRACE'.
      Add depends on PROC_FS since that is where the output goes.
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      LKML-Reference: <20100812123121.a7c99cde.randy.dunlap@oracle.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      625fdcaa
  24. 06 8月, 2010 1 次提交
    • R
      debugfs: no longer needs to depend on SYSFS · c462e8cd
      Randy Dunlap 提交于
      debugfs no longer uses 'kernel_subsys' (which is gone), and other
      kernel/ksysfs.c code is always built, so DEBUG_FS does not need
      to depend on SYSFS.
      
      Fixes this kconfig warning:
      
      warning: (TREE_RCU_TRACE || AMD_IOMMU_STATS && AMD_IOMMU || MTD_UBI_DEBUG && MTD && SYSFS && MTD_UBI || UBIFS_FS_DEBUG && MISC_FILESYSTEMS && UBIFS_FS || DEBUG_KMEMLEAK && DEBUG_KERNEL && EXPERIMENTAL && !MEMORY_HOTPLUG && (X86 || ARM || PPC || S390 || SPARC64 || SUPERH || MICROBLAZE) && SYSFS || TRACING || X86_PTDUMP && DEBUG_KERNEL || BLK_DEV_IO_TRACE && TRACING_SUPPORT && FTRACE && SYSFS && BLOCK) selects DEBUG_FS which has unmet direct dependencies (SYSFS)
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c462e8cd
  25. 04 8月, 2010 1 次提交
  26. 21 7月, 2010 1 次提交
  27. 19 7月, 2010 1 次提交
  28. 14 7月, 2010 1 次提交
    • A
      Kbuild: Add option to set -femit-struct-debug-baseonly · d6f4ceb7
      Andi Kleen 提交于
      Newer gcc has a -femit-struct-debug-baseonly option that dramatically
      reduces the size of object files with debug info. What it does
      is to only emit type information for structures when the structures
      are defined in the same file or in a header file.
      
      This means the type information for most headers are not included.
      This is not good when the type information is actually
      needed (e.g. with kgdb or systemtap)
      
      But often kernel hackers only care about line numbers and don't
      need all the type information anyways. In this case setting
      the option can be a big win:
      
      A build dir for a specific x86-64 configuration with gcc 4.5
      shrunk from 2.3G to 1.2G. The compilation was also nearly a minute
      faster.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      [mmarek: reformatted help text]
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      d6f4ceb7
  29. 15 6月, 2010 1 次提交
    • M
      tree/tiny rcu: Add debug RCU head objects · 551d55a9
      Mathieu Desnoyers 提交于
      Helps finding racy users of call_rcu(), which results in hangs because list
      entries are overwritten and/or skipped.
      
      Changelog since v4:
      - Bissectability is now OK
      - Now generate a WARN_ON_ONCE() for non-initialized rcu_head passed to
        call_rcu(). Statically initialized objects are detected with
        object_is_static().
      - Rename rcu_head_init_on_stack to init_rcu_head_on_stack.
      - Remove init_rcu_head() completely.
      
      Changelog since v3:
      - Include comments from Lai Jiangshan
      
      This new patch version is based on the debugobjects with the newly introduced
      "active state" tracker.
      
      Non-initialized entries are all considered as "statically initialized". An
      activation fixup (triggered by call_rcu()) takes care of performing the debug
      object initialization without issuing any warning. Since we cannot increase the
      size of struct rcu_head, I don't see much room to put an identifier for
      statically initialized rcu_head structures. So for now, we have to live without
      "activation without explicit init" detection. But the main purpose of this debug
      option is to detect double-activations (double call_rcu() use of a rcu_head
      before the callback is executed), which is correctly addressed here.
      
      This also detects potential internal RCU callback corruption, which would cause
      the callbacks to be executed twice.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      CC: akpm@linux-foundation.org
      CC: mingo@elte.hu
      CC: laijs@cn.fujitsu.com
      CC: dipankar@in.ibm.com
      CC: josh@joshtriplett.org
      CC: dvhltc@us.ibm.com
      CC: niv@us.ibm.com
      CC: tglx@linutronix.de
      CC: peterz@infradead.org
      CC: rostedt@goodmis.org
      CC: Valdis.Kletnieks@vt.edu
      CC: dhowells@redhat.com
      CC: eric.dumazet@gmail.com
      CC: Alexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Reviewed-by: NLai Jiangshan <laijs@cn.fujitsu.com>
      551d55a9
  30. 28 5月, 2010 1 次提交
  31. 25 5月, 2010 1 次提交
  32. 19 5月, 2010 1 次提交
  33. 16 5月, 2010 1 次提交
    • F
      lockup_detector: Introduce CONFIG_HARDLOCKUP_DETECTOR · 23637d47
      Frederic Weisbecker 提交于
      This new config is deemed to simplify even more the lockup detector
      dependencies and can make it easier to bring a smooth sorting
      between archs that support the new generic lockup detector and those
      that still have their own, especially for those that are in the
      middle of this migration.
      
      Instead of checking whether we have CONFIG_LOCKUP_DETECTOR +
      CONFIG_PERF_EVENTS_NMI each time an arch wants to know if it needs
      to build its own lockup detector, take a shortcut with this new
      config. It is enabled only if the hardlockup detection part of
      the whole lockup detector is on.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      23637d47