1. 01 5月, 2013 1 次提交
    • T
      dump_stack: consolidate dump_stack() implementations and unify their behaviors · 196779b9
      Tejun Heo 提交于
      Both dump_stack() and show_stack() are currently implemented by each
      architecture.  show_stack(NULL, NULL) dumps the backtrace for the
      current task as does dump_stack().  On some archs, dump_stack() prints
      extra information - pid, utsname and so on - in addition to the
      backtrace while the two are identical on other archs.
      
      The usages in arch-independent code of the two functions indicate
      show_stack(NULL, NULL) should print out bare backtrace while
      dump_stack() is used for debugging purposes when something went wrong,
      so it does make sense to print additional information on the task which
      triggered dump_stack().
      
      There's no reason to require archs to implement two separate but mostly
      identical functions.  It leads to unnecessary subtle information.
      
      This patch expands the dummy fallback dump_stack() implementation in
      lib/dump_stack.c such that it prints out debug information (taken from
      x86) and invokes show_stack(NULL, NULL) and drops arch-specific
      dump_stack() implementations in all archs except blackfin.  Blackfin's
      dump_stack() does something wonky that I don't understand.
      
      Debug information can be printed separately by calling
      dump_stack_print_info() so that arch-specific dump_stack()
      implementation can still emit the same debug information.  This is used
      in blackfin.
      
      This patch brings the following behavior changes.
      
      * On some archs, an extra level in backtrace for show_stack() could be
        printed.  This is because the top frame was determined in
        dump_stack() on those archs while generic dump_stack() can't do that
        reliably.  It can be compensated by inlining dump_stack() but not
        sure whether that'd be necessary.
      
      * Most archs didn't use to print debug info on dump_stack().  They do
        now.
      
      An example WARN dump follows.
      
       WARNING: at kernel/workqueue.c:4841 init_workqueues+0x35/0x505()
       Hardware name: empty
       Modules linked in:
       CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.9.0-rc1-work+ #9
        0000000000000009 ffff88007c861e08 ffffffff81c614dc ffff88007c861e48
        ffffffff8108f50f ffffffff82228240 0000000000000040 ffffffff8234a03c
        0000000000000000 0000000000000000 0000000000000000 ffff88007c861e58
       Call Trace:
        [<ffffffff81c614dc>] dump_stack+0x19/0x1b
        [<ffffffff8108f50f>] warn_slowpath_common+0x7f/0xc0
        [<ffffffff8108f56a>] warn_slowpath_null+0x1a/0x20
        [<ffffffff8234a071>] init_workqueues+0x35/0x505
        ...
      
      v2: CPU number added to the generic debug info as requested by s390
          folks and dropped the s390 specific dump_stack().  This loses %ksp
          from the debug message which the maintainers think isn't important
          enough to keep the s390-specific dump_stack() implementation.
      
          dump_stack_print_info() is moved to kernel/printk.c from
          lib/dump_stack.c.  Because linkage is per objecct file,
          dump_stack_print_info() living in the same lib file as generic
          dump_stack() means that archs which implement custom dump_stack()
          - at this point, only blackfin - can't use dump_stack_print_info()
          as that will bring in the generic version of dump_stack() too.  v1
          The v1 patch broke build on blackfin due to this issue.  The build
          breakage was reported by Fengguang Wu.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Acked-by: NJesper Nilsson <jesper.nilsson@axis.com>
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>	[s390 bits]
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Acked-by: Richard Kuo <rkuo@codeaurora.org>		[hexagon bits]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      196779b9
  2. 30 4月, 2013 1 次提交
  3. 17 4月, 2013 1 次提交
  4. 09 4月, 2013 1 次提交
    • C
      ARC: Add implicit compiler barrier to raw_local_irq* functions · 79e5f05e
      Christian Ruppert 提交于
      ARC irqsave/restore macros were missing the compiler barrier, causing a
      stale load in irq-enabled region be used in irq-safe region, despite
      being changed, because the register holding the value was still live.
      
      The problem manifested as random crashes in timer code when stress
      testing ARCLinux (3.9-rc3) on a !SMP && !PREEMPT_COUNT
      
      Here's the exact sequence which caused this:
       (0). tv1[x] <----> t1 <---> t2
       (1). mod_timer(t1) interrupted after it calls timer_pending()
       (2). mod_timer(t2) completes
       (3). mod_timer(t1) resumes but messes up the list
       (4). __runt_timers( ) uses bogus timer_list entry / crashes in
            timer->function
      
      Essentially mod_timer() was racing against itself and while the spinlock
      serialized the tv1[] timer link list, timer_pending() called outside the
      spinlock, cached timer link list element in a register.
      With low register pressure (and a deep register file), lack of barrier
      in raw_local_irqsave() as well as preempt_disable (!PREEMPT_COUNT
      version), there was nothing to force gcc to reload across the spinlock,
      causing a stale value in reg be used for link list manipulation - ensuing
      a corruption.
      
      ARcompact disassembly which shows the culprit generated code:
      
      mod_timer:
          push_s blink
          mov_s r13,r0	# timer, timer
      ..
          ###### timer_pending( )
          ld_s r3,[r13]       # <------ <variable>.entry.next LOADED
          brne r3, 0, @.L163
      
      .L163:
      ..
          ###### spin_lock_irq( )
          lr  r5, [status32]  # flags
          bic r4, r5, 6       # temp, flags,
          and.f 0, r5, 6      # flags,
          flag.nz r4
      
          ###### detach_if_pending( ) begins
      
          tst_s r3,r3  <--------------
      			# timer_pending( ) checks timer->entry.next
                              # r3 is NOT reloaded by gcc, using stale value
          beq.d @.L169
          mov.eq r0,0
      
          #####  detach_timer( ): __list_del( )
      
          ld r4,[r13,4]    	# <variable>.entry.prev, D.31439
          st r4,[r3,4]     	# <variable>.prev, D.31439
          st r3,[r4]       	# <variable>.next, D.30246
      
      We initially tried to fix this by adding barrier() to preempt_* macros
      for !PREEMPT_COUNT but Linus clarified that it was anything but wrong.
      http://www.spinics.net/lists/kernel/msg1512709.html
      
      [vgupta: updated commitlog]
      
      Reported-by/Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com>
      Cc: Christian Ruppert <christian.ruppert@abilis.com>
      Cc: Pierrick Hascoet <pierrick.hascoet@abilis.com>
      Debugged-by/Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      79e5f05e
  5. 08 4月, 2013 1 次提交
  6. 20 3月, 2013 1 次提交
    • V
      ARC: Fix the typo in event identifier flags used by ptrace · 367f3fcd
      Vineet Gupta 提交于
      orig_r8_IS_EXCPN and orig_r8_IS_BRKPT were same values due to a
      copy/paste error. Although it looks bad and is wrong, it really doesn't
      affect gdb working.
      
      orig_r8_IS_BRKPT is the one relevant to debugging (breakpoints), since
      it is used to provide EFA vs. ERET to a ptrace "stop_pc" request.
      
      So when gdb has inserted a breakpoint, orig_r8_IS_BRKPT is already set,
      and anything else (i.e. orig_r8_IS_EXCPN) becoming same as it, really
      doesn't hurt gdb. The corollary case, could be nasty but nobody uses the
      ptrace "stop_pc" request in that case
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      367f3fcd
  7. 19 3月, 2013 1 次提交
  8. 18 3月, 2013 3 次提交
  9. 11 3月, 2013 3 次提交
    • V
      ARC: ABIv3: fork/vfork wrappers not needed in "no-legacy-syscall" ABI · 180d406e
      Vineet Gupta 提交于
      When switching to clone() only ABI - I missed out pruning the low level
      asm syscall wrappers
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      180d406e
    • V
      ARC: ABIv3: Print the correct ABI ver · 8ff14bbc
      Vineet Gupta 提交于
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      8ff14bbc
    • V
      ARC: make allyesconfig build breakages · 1540c85b
      Vineet Gupta 提交于
        CC      drivers/mmc/host/mmc_spi.o
      drivers/mmc/host/mmc_spi.c:118: error: redefinition of 'struct scratch'
      make[3]: *** [drivers/mmc/host/mmc_spi.o] Error 1
      make[2]: *** [drivers/mmc/host] Error 2
      make[1]: *** [drivers/mmc] Error 2
      make: *** [drivers] Error 2
      
        CC      arch/arc/kernel/kgdb.o
      In file included from include/linux/kgdb.h:20,
                       from arch/arc/kernel/kgdb.c:11:
      /home/vineetg/arc/k.org/arc-port/arch/arc/include/asm/kgdb.h:34:
      warning: 'struct pt_regs' declared inside parameter list
      /home/vineetg/arc/k.org/arc-port/arch/arc/include/asm/kgdb.h:34:
      warning: its scope is only this definition or declaration, which is
      probably not what you want
      arch/arc/kernel/kgdb.c:172: error: conflicting types for 'kgdb_trap'
      
        CC      arch/arc/kernel/kgdb.o
      arch/arc/kernel/kgdb.c: In function 'pt_regs_to_gdb_regs':
      arch/arc/kernel/kgdb.c:62: error: dereferencing pointer to incomplete
      type
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      1540c85b
  10. 27 2月, 2013 3 次提交
  11. 26 2月, 2013 2 次提交
  12. 16 2月, 2013 22 次提交