1. 12 8月, 2010 1 次提交
  2. 11 8月, 2010 1 次提交
  3. 10 8月, 2010 11 次提交
  4. 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
  5. 04 8月, 2010 1 次提交
  6. 29 7月, 2010 1 次提交
    • C
      lib/scatterlist: Hook sg_kmalloc into kmemleak (v2) · b94de9bb
      Chris Wilson 提交于
      kmemleak ignores page_alloc() and so believes the final sub-page
      allocation using the plain kmalloc is decoupled and lost. This leads to
      lots of false-positives with code that uses scatterlists.
      
      The options seem to be either to tell kmemleak that the kmalloc is not
      leaked or to notify kmemleak of the page allocations. The danger of the
      first approach is that we may hide a real leak, so choose the latter
      approach (of which I am not sure of the downsides).
      
      v2: Added comments on the suggestion of Catalin.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Jens Axboe <jaxboe@fusionio.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      b94de9bb
  7. 27 7月, 2010 1 次提交
  8. 21 7月, 2010 1 次提交
  9. 19 7月, 2010 1 次提交
  10. 14 7月, 2010 2 次提交
  11. 12 7月, 2010 1 次提交
  12. 10 7月, 2010 1 次提交
    • K
      x86, ioremap: Fix incorrect physical address handling in PAE mode · ffa71f33
      Kenji Kaneshige 提交于
      Current x86 ioremap() doesn't handle physical address higher than
      32-bit properly in X86_32 PAE mode. When physical address higher than
      32-bit is passed to ioremap(), higher 32-bits in physical address is
      cleared wrongly. Due to this bug, ioremap() can map wrong address to
      linear address space.
      
      In my case, 64-bit MMIO region was assigned to a PCI device (ioat
      device) on my system. Because of the ioremap()'s bug, wrong physical
      address (instead of MMIO region) was mapped to linear address space.
      Because of this, loading ioatdma driver caused unexpected behavior
      (kernel panic, kernel hangup, ...).
      Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      LKML-Reference: <4C1AE680.7090408@jp.fujitsu.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      ffa71f33
  13. 05 7月, 2010 3 次提交
  14. 30 6月, 2010 1 次提交
  15. 23 6月, 2010 1 次提交
  16. 17 6月, 2010 1 次提交
  17. 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
  18. 07 6月, 2010 5 次提交
  19. 05 6月, 2010 3 次提交
  20. 31 5月, 2010 1 次提交
  21. 28 5月, 2010 1 次提交