An error occurred fetching the project authors.
  1. 12 Aug, 2013 1 commit
  2. 01 May, 2013 1 commit
    • Tejun Heo's avatar
      dump_stack: consolidate dump_stack() implementations and unify their behaviors · 196779b9
      Tejun Heo authored
      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: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Acked-by: default avatarJesper Nilsson <jesper.nilsson@axis.com>
      Acked-by: default avatarVineet 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      196779b9
  3. 21 Jan, 2013 1 commit
  4. 07 Sep, 2012 1 commit
  5. 31 Jul, 2012 1 commit
    • Russell King's avatar
      ARM: Fix undefined instruction exception handling · 15ac49b6
      Russell King authored
      While trying to get a v3.5 kernel booted on the cubox, I noticed that
      VFP does not work correctly with VFP bounce handling.  This is because
      of the confusion over 16-bit vs 32-bit instructions, and where PC is
      supposed to point to.
      
      The rule is that FP handlers are entered with regs->ARM_pc pointing at
      the _next_ instruction to be executed.  However, if the exception is
      not handled, regs->ARM_pc points at the faulting instruction.
      
      This is easy for ARM mode, because we know that the next instruction and
      previous instructions are separated by four bytes.  This is not true of
      Thumb2 though.
      
      Since all FP instructions are 32-bit in Thumb2, it makes things easy.
      We just need to select the appropriate adjustment.  Do this by moving
      the adjustment out of do_undefinstr() into the assembly code, as only
      the assembly code knows whether it's dealing with a 32-bit or 16-bit
      instruction.
      
      Cc: <stable@vger.kernel.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      15ac49b6
  6. 28 Jul, 2012 1 commit
  7. 09 Jul, 2012 1 commit
    • Rabin Vincent's avatar
      ARM: 7424/1: update die handler from x86 · 02df19b4
      Rabin Vincent authored
      Robustify ARM's die() handling with improvements from x86:
      
       - Fix for a deadlock (before panic in the case of panic_on_oops) if we
         oops under a spinlock which is also used from interrupt handler,
         since the old code was unconditionally enabling interrupts.
      
       - Usage of arch spinlock so lockdep etc doesn't get involved while
         we're trying to dump out oopses.
      
       - Deadlock prevention in the unlikely event that die() recurses.
      
      The changes all touch the same few lines of code, so they're done
      together in one patch.
      Signed-off-by: default avatarRabin Vincent <rabin.vincent@stericsson.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      02df19b4
  8. 05 Jul, 2012 1 commit
  9. 21 May, 2012 1 commit
  10. 02 May, 2012 2 commits
  11. 19 Apr, 2012 1 commit
  12. 28 Mar, 2012 1 commit
  13. 24 Mar, 2012 1 commit
  14. 09 Feb, 2012 1 commit
  15. 23 Jan, 2012 1 commit
  16. 17 Oct, 2011 2 commits
    • Simon Glass's avatar
      ARM: 7017/1: Use generic BUG() handler · 87e040b6
      Simon Glass authored
      ARM uses its own BUG() handler which makes its output slightly different
      from other archtectures.
      
      One of the problems is that the ARM implementation doesn't report the function
      with the BUG() in it, but always reports the PC being in __bug(). The generic
      implementation doesn't have this problem.
      
      Currently we get something like:
      
      kernel BUG at fs/proc/breakme.c:35!
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      ...
      PC is at __bug+0x20/0x2c
      
      With this patch it displays:
      
      kernel BUG at fs/proc/breakme.c:35!
      Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP
      ...
      PC is at write_breakme+0xd0/0x1b4
      
      This implementation uses an undefined instruction to implement BUG, and sets up
      a bug table containing the relevant information. Many versions of gcc do not
      support %c properly for ARM (inserting a # when they shouldn't) so we work
      around this using distasteful macro magic.
      
      v1: Initial version to replace existing ARM BUG() implementation with something
      more similar to other architectures.
      
      v2: Add Thumb support, remove backtrace whitespace output changes. Change to
      use macros instead of requiring the asm %d flag to work (thanks to
      Dave Martin <dave.martin@linaro.org>)
      
      v3: Remove old BUG() implementation in favor of this one.
      Remove the Backtrace: message (will submit this separately).
      Use ARM_EXIT_KEEP() so that some architectures can dump exit text at link time
      thanks to Stephen Boyd <sboyd@codeaurora.org> (although since we always
      define GENERIC_BUG this might be academic.)
      Rebase to linux-2.6.git master.
      
      v4: Allow BUGS in modules (these were not reported correctly in v3)
      (thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting that.)
      Remove __bug() as this is no longer needed.
      
      v5: Add %progbits as the section flags.
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      Reviewed-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Tested-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      87e040b6
    • Jamie Iles's avatar
      ARM: 7115/4: move __exception and friends to asm/exception.h · 5a567d78
      Jamie Iles authored
      The definition of __exception_irq_entry for
      CONFIG_FUNCTION_GRAPH_TRACER=y needs linux/ftrace.h, but this creates a
      circular dependency with it's current home in asm/system.h. Create
      asm/exception.h and update all current users.
      
      v4:	- rebase to rmk/for-next
      v3:	- remove redundant includes of linux/ftrace.h
      v2:	- document the usage restricitions of __exception*
      
      Cc: Zoltan Devai <zdevai@gmail.com>
      Signed-off-by: default avatarJamie Iles <jamie@jamieiles.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      5a567d78
  17. 13 Sep, 2011 1 commit
  18. 26 Jul, 2011 1 commit
  19. 13 Jul, 2011 1 commit
    • Jon Medhurst's avatar
      ARM: Thumb-2: Support Thumb-2 in undefined instruction handler · 592201a9
      Jon Medhurst authored
      This patch allows undef_hook's to be specified for 32-bit Thumb
      instructions and also to be used for thumb kernel-side code.
      
      32-bit Thumb instructions are specified in the form:
      	((first_half << 16 ) | second_half)
      which matches the layout used by the ARM ARM.
      
      ptrace was handling 32-bit Thumb instructions by hooking the first
      halfword and manually checking the second half. This method would be
      broken by this patch so it is migrated to make use of the new Thumb-2
      support.
      Signed-off-by: default avatarJon Medhurst <tixy@yxit.co.uk>
      Acked-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      592201a9
  20. 09 Jun, 2011 2 commits
  21. 13 May, 2011 1 commit
  22. 14 Apr, 2011 1 commit
  23. 23 Feb, 2011 2 commits
    • Will Deacon's avatar
      ARM: 6668/1: ptrace: remove single-step emulation code · 425fc47a
      Will Deacon authored
      PTRACE_SINGLESTEP is a ptrace request designed to offer single-stepping
      support to userspace when the underlying architecture has hardware
      support for this operation.
      
      On ARM, we set arch_has_single_step() to 1 and attempt to emulate hardware
      single-stepping by disassembling the current instruction to determine the
      next pc and placing a software breakpoint on that location.
      
      Unfortunately this has the following problems:
      
      1.) Only a subset of ARMv7 instructions are supported
      2.) Thumb-2 is unsupported
      3.) The code is not SMP safe
      
      We could try to fix this code, but it turns out that because of the above
      issues it is rarely used in practice.  GDB, for example, uses PTRACE_POKETEXT
      and PTRACE_PEEKTEXT to manage breakpoints itself and does not require any
      kernel assistance.
      
      This patch removes the single-step emulation code from ptrace meaning that
      the PTRACE_SINGLESTEP request will return -EIO on ARM. Portable code must
      check the return value from a ptrace call and handle the failure gracefully.
      Acked-by: default avatarNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      425fc47a
    • Russell King's avatar
      ARM: fix some sparse errors in generic ARM code · 2bbd7e9b
      Russell King authored
      arch/arm/kernel/return_address.c:37:6: warning: symbol 'return_address' was not declared. Should it be static?
      arch/arm/kernel/setup.c:76:14: warning: symbol 'processor_id' was not declared. Should it be static?
      arch/arm/kernel/traps.c:259:1: warning: symbol 'die_lock' was not declared. Should it be static?
      arch/arm/vfp/vfpmodule.c:156:6: warning: symbol 'vfp_raise_sigfpe' was not declared. Should it be static?
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      2bbd7e9b
  24. 15 Feb, 2011 1 commit
  25. 26 Nov, 2010 1 commit
  26. 07 Nov, 2010 1 commit
  27. 04 Nov, 2010 1 commit
    • Catalin Marinas's avatar
      ARM: 6384/1: Remove the domain switching on ARMv6k/v7 CPUs · 247055aa
      Catalin Marinas authored
      This patch removes the domain switching functionality via the set_fs and
      __switch_to functions on cores that have a TLS register.
      
      Currently, the ioremap and vmalloc areas share the same level 1 page
      tables and therefore have the same domain (DOMAIN_KERNEL). When the
      kernel domain is modified from Client to Manager (via the __set_fs or in
      the __switch_to function), the XN (eXecute Never) bit is overridden and
      newer CPUs can speculatively prefetch the ioremap'ed memory.
      
      Linux performs the kernel domain switching to allow user-specific
      functions (copy_to/from_user, get/put_user etc.) to access kernel
      memory. In order for these functions to work with the kernel domain set
      to Client, the patch modifies the LDRT/STRT and related instructions to
      the LDR/STR ones.
      
      The user pages access rights are also modified for kernel read-only
      access rather than read/write so that the copy-on-write mechanism still
      works. CPU_USE_DOMAINS gets disabled only if the hardware has a TLS register
      (CPU_32v6K is defined) since writing the TLS value to the high vectors page
      isn't possible.
      
      The user addresses passed to the kernel are checked by the access_ok()
      function so that they do not point to the kernel space.
      Tested-by: default avatarAnton Vorontsov <cbouatmailru@gmail.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      247055aa
  28. 09 Jul, 2010 1 commit
  29. 15 Feb, 2010 1 commit
  30. 10 Nov, 2009 1 commit
  31. 08 Nov, 2009 1 commit
  32. 25 Oct, 2009 1 commit
  33. 11 Oct, 2009 3 commits
  34. 28 Sep, 2009 1 commit