1. 17 10月, 2008 11 次提交
  2. 14 10月, 2008 1 次提交
  3. 09 10月, 2008 5 次提交
    • J
      block: add fault injection mechanism for faking request timeouts · 581d4e28
      Jens Axboe 提交于
      Only works for the generic request timer handling. Allows one to
      sporadically ignore request completions, thus exercising the timeout
      handling.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      581d4e28
    • T
      init: DEBUG_BLOCK_EXT_DEVT requires explicit root= param · 55dc7db7
      Tejun Heo 提交于
      DEBUG_BLOCK_EXT_DEVT shuffles SCSI and IDE device numbers and root
      device number set using rdev become meaningless.  Root devices should
      be explicitly specified using textual names.  Warn about it if root
      can't be found and DEBUG_BLOCK_EXT_DEVT is enabled.  Also, add warning
      to the help text.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      55dc7db7
    • J
      Change default value of CONFIG_DEBUG_BLOCK_EXT_DEVT to 'n' · 759f8ca3
      Jens Axboe 提交于
      It's a debug option that you would explicitly enable to test this
      feature, we should default it to 'n' to prevent accidental surprises
      for now.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      759f8ca3
    • T
      block: implement CONFIG_DEBUG_BLOCK_EXT_DEVT · 870d6656
      Tejun Heo 提交于
      Extended devt introduces non-contiguos device numbers.  This patch
      implements a debug option which forces most devt allocations to be
      from the extended area and spreads them out.  This is enabled by
      default if DEBUG_KERNEL is set and achieves...
      
      1. Detects code paths in kernel or userland which expect predetermined
         consecutive device numbers.
      
      2. When something goes wrong, avoid corruption as adding to the minor
         of earlier partition won't lead to the wrong but valid device.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      870d6656
    • T
      klist: don't iterate over deleted entries · a1ed5b0c
      Tejun Heo 提交于
      A klist entry is kept on the list till all its current iterations are
      finished; however, a new iteration after deletion also iterates over
      deleted entries as long as their reference count stays above zero.
      This causes problems for cases where there are users which iterate
      over the list while synchronized against list manipulations and
      natuarally expect already deleted entries to not show up during
      iteration.
      
      This patch implements dead flag which gets set on deletion so that
      iteration can skip already deleted entries.  The dead flag piggy backs
      on the lowest bit of knode->n_klist and only visible to klist
      implementation proper.
      
      While at it, drop klist_iter->i_head as it's redundant and doesn't
      offer anything in semantics or performance wise as klist_iter->i_klist
      is dereferenced on every iteration anyway.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      a1ed5b0c
  4. 04 10月, 2008 1 次提交
  5. 03 10月, 2008 1 次提交
    • P
      rcu: RCU-based detection of stalled CPUs for Classic RCU · 2133b5d7
      Paul E. McKenney 提交于
      This patch adds stalled-CPU detection to Classic RCU.  This capability
      is enabled by a new config variable CONFIG_RCU_CPU_STALL_DETECTOR, which
      defaults disabled.
      
      This is a debugging feature to detect infinite loops in kernel code, not
      something that non-kernel-hackers would be expected to care about.
      
      This feature can detect looping CPUs in !PREEMPT builds and looping CPUs
      with preemption disabled in PREEMPT builds.  This is essentially a port of
      this functionality from the treercu patch, replacing the stall debug patch
      that is already in tip/core/rcu (commit 67182ae1).
      
      The changes from the patch in tip/core/rcu include making the config
      variable name match that in treercu, changing from seconds to jiffies to
      avoid spurious warnings, and printing a boot message when this feature
      is enabled.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2133b5d7
  6. 22 9月, 2008 1 次提交
  7. 19 9月, 2008 1 次提交
  8. 12 9月, 2008 1 次提交
  9. 11 9月, 2008 1 次提交
    • D
      swiotlb: fix back-off path when memory allocation fails · 36223a39
      Daniel J Blueman 提交于
      This fixes a SWIOTLB oops
      
      With SWIOTLB being enabled and straight-forward page allocation
      failure [1], the swiotlb_alloc_coherent fall-back path hits an
      issue [2], resulting in my webcam failing to work.
      
      At the time of oops, RDI is clearly a pointer to a structure which
      has arrived as NULL, leading to the typo in swiotlb_map_single's
      callsite arguments.
      
      Correctly passing the device structure [3] addresses the issue and
      gets my webcam working again (the allocation failure still occuring).
      
       --- [1]
      
      skype: page allocation failure. order:3, mode:0x1
      Pid: 5895, comm: skype Not tainted 2.6.27-rc6-235c-debug #1
      
      Call Trace:
       [<ffffffff802b7cf0>] __alloc_pages_internal+0x4a0/0x5d0
       [<ffffffff802d5ddd>] alloc_pages_current+0xad/0x110
       [<ffffffff802b4ccd>] __get_free_pages+0x1d/0x60
       [<ffffffff8046cd39>] swiotlb_alloc_coherent+0x49/0x180
       [<ffffffff80212731>] dma_alloc_coherent+0x281/0x310
       [<ffffffff805621c0>] hcd_buffer_alloc+0x50/0x90
       [<ffffffff805547fd>] usb_buffer_alloc+0x2d/0x40
       [<ffffffffa0056763>] uvc_alloc_urb_buffers+0x53/0xf0 [uvcvideo]
       [<ffffffffa0056958>] uvc_init_video+0x158/0x3e0 [uvcvideo]
       [<ffffffffa0056c17>] uvc_video_enable+0x37/0x80 [uvcvideo]
       [<ffffffffa0055853>] uvc_v4l2_do_ioctl+0x723/0x1260 [uvcvideo]
       [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0
       [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0
       [<ffffffffa0032c9f>] video_usercopy+0x19f/0x390 [videodev]
       [<ffffffffa0055130>] ? uvc_v4l2_do_ioctl+0x0/0x1260 [uvcvideo]
       [<ffffffff8026d0ce>] ? put_lock_stats+0xe/0x30
       [<ffffffffa0054dad>] uvc_v4l2_ioctl+0x4d/0x80 [uvcvideo]
       [<ffffffffa0045083>] native_ioctl+0x83/0x90 [compat_ioctl32]
       [<ffffffffa004534e>] v4l_compat_ioctl32+0x2be/0x1da4 [compat_ioctl32]
       [<ffffffff806aad21>] ? do_page_fault+0x3d1/0xae0
       [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff80270c59>] ? trace_hardirqs_on_caller+0x149/0x1b0
       [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff80329afa>] compat_sys_ioctl+0x8a/0x3c0
       [<ffffffff806a700d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
       [<ffffffff8022f816>] sysenter_dispatch+0x7/0x2c
       [<ffffffff806a6fce>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      
      Mem-Info:
      Node 0 DMA per-cpu:
      CPU    0: hi:    0, btch:   1 usd:   0
      CPU    1: hi:    0, btch:   1 usd:   0
      Node 0 DMA32 per-cpu:
      CPU    0: hi:  186, btch:  31 usd:   3
      CPU    1: hi:  186, btch:  31 usd:   0
      Node 0 Normal per-cpu:
      CPU    0: hi:  186, btch:  31 usd:  23
      CPU    1: hi:  186, btch:  31 usd: 179
      Active:78545 inactive:48683 dirty:31 writeback:0 unstable:2
       free:830202 slab:17516 mapped:17473 pagetables:3496 bounce:0
      Node 0 DMA free:36kB min:28kB low:32kB high:40kB active:0kB
      inactive:0kB present:15156kB pages_scanned:0 all_unreclaimable? no
      lowmem_reserve[]: 0 3207 3956 3956
      Node 0 DMA32 free:3197192kB min:6512kB low:8140kB high:9768kB
      active:0kB inactive:0kB present:3284896kB pages_scanned:0
      all_unreclaimable? no
      lowmem_reserve[]: 0 0 748 748
      Node 0 Normal free:123580kB min:1516kB low:1892kB high:2272kB
      active:314180kB inactive:194732kB present:766464kB pages_scanned:0
      all_unreclaimable? no
      lowmem_reserve[]: 0 0 0 0
      Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB
      0*1024kB 0*2048kB 0*4096kB = 36kB
      Node 0 DMA32: 4*4kB 3*8kB 2*16kB 3*32kB 4*64kB 5*128kB 3*256kB 5*512kB
      4*1024kB 5*2048kB 776*4096kB = 3197224kB
      Node 0 Normal: 14*4kB 14*8kB 8*16kB 6*32kB 1*64kB 3*128kB 3*256kB
      2*512kB 4*1024kB 1*2048kB 28*4096kB = 123560kB
      64847 total pagecache pages
      0 pages in swap cache
      Swap cache stats: add 0, delete 0, find 0/0
      Free swap  = 502752kB
      Total swap = 502752kB
      1048576 pages RAM
      52120 pages reserved
      71967 pages shared
      143004 pages non-shared
      
       --- [2]
      
      BUG: unable to handle kernel NULL pointer dereference at 00000000000002c8
      IP: [<ffffffff8046c84c>] map_single+0x1c/0x280
      PGD 10e54e067 PUD 10e595067 PMD 0
      Oops: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC
      CPU 0
      Modules linked in: kvm_intel kvm microcode uvcvideo compat_ioctl32
      videodev v4l1_compat shpchp pci_hotplug
      Pid: 5895, comm: skype Not tainted 2.6.27-rc6-235c-debug #1
      RIP: 0010:[<ffffffff8046c84c>]  [<ffffffff8046c84c>] map_single+0x1c/0x280
      RSP: 0018:ffff88010e78d988  EFLAGS: 00210296
      RAX: 0000780000000000 RBX: 0000000000000000 RCX: 0000000000000002
      RDX: 0000000000005000 RSI: 0000000000000000 RDI: 0000000000000000
      RBP: ffff88010e78d9e8 R08: 0000000000000000 R09: 0000000000000001
      R10: ffff88010e78d698 R11: 0000000000000001 R12: 0000000000000002
      R13: 0000000000000000 R14: 0000000000005000 R15: ffff88012f1c9968
      FS:  0000000000000000(0000) GS:ffffffff80a6cdc0(0063) knlGS:00000000f6355b90
      CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
      CR2: 00000000000002c8 CR3: 000000010e57d000 CR4: 00000000000026e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process skype (pid: 5895, threadinfo ffff88010e78c000, task ffff88012b9cc460)
      Stack:  0000000200000000 0000000000005000 0000000000000000 0000000000000000
       00000000000017b8 0000000000000000 ffff88010e78d9c8 0000000000000000
       0000000000000002 0000000000000000 0000000000005000 ffff88012f1c9968
      Call Trace:
       [<ffffffff8046cbb0>] swiotlb_map_single_attrs+0x60/0xf0
       [<ffffffff8046cc4c>] swiotlb_map_single+0xc/0x10
       [<ffffffff8046cdee>] swiotlb_alloc_coherent+0xfe/0x180
       [<ffffffff80212731>] dma_alloc_coherent+0x281/0x310
       [<ffffffff805621c0>] hcd_buffer_alloc+0x50/0x90
       [<ffffffff805547fd>] usb_buffer_alloc+0x2d/0x40
       [<ffffffffa0056763>] uvc_alloc_urb_buffers+0x53/0xf0 [uvcvideo]
       [<ffffffffa0056958>] uvc_init_video+0x158/0x3e0 [uvcvideo]
       [<ffffffffa0056c17>] uvc_video_enable+0x37/0x80 [uvcvideo]
       [<ffffffffa0055853>] uvc_v4l2_do_ioctl+0x723/0x1260 [uvcvideo]
       [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0
       [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0
       [<ffffffffa0032c9f>] video_usercopy+0x19f/0x390 [videodev]
       [<ffffffffa0055130>] ? uvc_v4l2_do_ioctl+0x0/0x1260 [uvcvideo]
       [<ffffffff8026d0ce>] ? put_lock_stats+0xe/0x30
       [<ffffffffa0054dad>] uvc_v4l2_ioctl+0x4d/0x80 [uvcvideo]
       [<ffffffffa0045083>] native_ioctl+0x83/0x90 [compat_ioctl32]
       [<ffffffffa004534e>] v4l_compat_ioctl32+0x2be/0x1da4 [compat_ioctl32]
       [<ffffffff806aad21>] ? do_page_fault+0x3d1/0xae0
       [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff80270c59>] ? trace_hardirqs_on_caller+0x149/0x1b0
       [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff80329afa>] compat_sys_ioctl+0x8a/0x3c0
       [<ffffffff806a700d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
       [<ffffffff8022f816>] sysenter_dispatch+0x7/0x2c
       [<ffffffff806a6fce>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      
      Code: 45 31 c0 48 89 e5 e8 a4 ff ff ff c9 c3 66 90 55 48 89 e5 41 57
      41 56 41 55 41 54 53 48 83 ec 38 48 89 75 b0 48 89 55 a8 89 4d a4 <48>
      8b 87 c8 02 00 00 48 85 c0 0f 84 1c 02 00 00 48 8b 58 08 48
      RIP  [<ffffffff8046c84c>] map_single+0x1c/0x280
       RSP <ffff88010e78d988>
      CR2: 00000000000002c8
      ---[ end trace 5d15baeeb7025a0e ]---
      
       --- [3]
      
      ffffffff8046c830 <map_single>:
      map_single():
      /store/kernel/linux/lib/swiotlb.c:291
      ffffffff8046c830:       55                      push   %rbp
      ffffffff8046c831:       48 89 e5                mov    %rsp,%rbp
      ffffffff8046c834:       41 57                   push   %r15
      ffffffff8046c836:       41 56                   push   %r14
      ffffffff8046c838:       41 55                   push   %r13
      ffffffff8046c83a:       41 54                   push   %r12
      ffffffff8046c83c:       53                      push   %rbx
      ffffffff8046c83d:       48 83 ec 38             sub    $0x38,%rsp
      ffffffff8046c841:       48 89 75 b0             mov    %rsi,-0x50(%rbp)
      ffffffff8046c845:       48 89 55 a8             mov    %rdx,-0x58(%rbp)
      ffffffff8046c849:       89 4d a4                mov    %ecx,-0x5c(%rbp)
      dma_get_seg_boundary():
      /store/kernel/linux/include/linux/dma-mapping.h:80
      ffffffff8046c84c:       48 8b 87 c8 02 00 00    mov    0x2c8(%rdi),%rax <----
      
       --- [4]
      Signed-off-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      36223a39
  10. 10 9月, 2008 2 次提交
  11. 08 9月, 2008 4 次提交
  12. 03 9月, 2008 1 次提交
    • T
      powerpc: Work around gcc's -fno-omit-frame-pointer bug · 7563dc64
      Tony Breeds 提交于
      This bug is causing random crashes
      (http://bugzilla.kernel.org/show_bug.cgi?id=11414).
      
      -fno-omit-frame-pointer is only needed on powerpc when -pg is also
      supplied, and there is a gcc bug that causes incorrect code generation
      on 32-bit powerpc when -fno-omit-frame-pointer is used---it uses stack
      locations below the stack pointer, which is not allowed by the ABI
      because those locations can and sometimes do get corrupted by an
      interrupt.
      
      This ensures that CONFIG_FRAME_POINTER is only selected by ftrace.
      When CONFIG_FTRACE is enabled we also pass -mno-sched-epilog to work
      around the gcc codegen bug.
      
      Patch based on work by:
      	Andreas Schwab <schwab@suse.de>
      	Segher Boessenkool <segher@kernel.crashing.org>
      Signed-off-by: NTony Breeds <tony@bakeyournoodle.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      7563dc64
  13. 01 9月, 2008 1 次提交
    • V
      debugobjects: fix lockdep warning · 673d62cc
      Vegard Nossum 提交于
      Daniel J. Blueman reported:
      > =======================================================
      > [ INFO: possible circular locking dependency detected ]
      > 2.6.27-rc4-224c #1
      > -------------------------------------------------------
      > hald/4680 is trying to acquire lock:
      >  (&n->list_lock){++..}, at: [<ffffffff802bfa26>] add_partial+0x26/0x80
      >
      > but task is already holding lock:
      >  (&obj_hash[i].lock){++..}, at: [<ffffffff8041cfdc>]
      > debug_object_free+0x5c/0x120
      
      We fix it by moving the actual freeing to outside the lock (the lock
      now only protects the list).
      
      The pool lock is also promoted to irq-safe (suggested by Dan). It's
      necessary because free_pool is now called outside the irq disabled
      region. So we need to protect against an interrupt handler which calls
      debug_object_init().
      
      [tglx@linutronix.de: added hlist_move_list helper to avoid looping
      		     through the list twice]
      Reported-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      673d62cc
  14. 22 8月, 2008 1 次提交
  15. 10 10月, 2008 1 次提交
  16. 17 8月, 2008 1 次提交
  17. 16 8月, 2008 1 次提交
  18. 13 8月, 2008 3 次提交
  19. 11 8月, 2008 1 次提交
    • P
      rcu, debug: detect stalled grace periods · 67182ae1
      Paul E. McKenney 提交于
      this is a diagnostic patch for Classic RCU.
      
      The approach is to record a timestamp at the beginning
      of the grace period (in rcu_start_batch()), then have
      rcu_check_callbacks() complain if:
      
       1.	it is running on a CPU that has holding up grace periods for
       	a long time (say one second).  This will identify the culprit
       	assuming that the culprit has not disabled hardware irqs,
       	instruction execution, or some such.
      
       2.	it is running on a CPU that is not holding up grace periods,
       	but grace periods have been held up for an even longer time
       	(say two seconds).
      
      It is enabled via the default-off CONFIG_DEBUG_RCU_STALL kernel parameter.
      
      Rather than exponential backoff, it backs off to once per 30 seconds.
      My feeling upon thinking on it was that if you have stalled RCU grace
      periods for that long, a few extra printk() messages are probably the
      least of your worries...
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Cc: David Witbrodt <dawitbro@sbcglobal.net>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      67182ae1
  20. 01 8月, 2008 1 次提交