1. 21 Aug, 2015 1 commit
  2. 02 Jun, 2015 1 commit
  3. 12 Apr, 2015 1 commit
  4. 27 Nov, 2014 1 commit
  5. 21 Nov, 2014 1 commit
  6. 17 Sep, 2014 2 commits
    • Russell King's avatar
      ARM: remove unused do_unexp_fiq() function · 3467e765
      Russell King authored
      
      
      do_unexp_fiq() has never been called by any code in the last 10 years,
      it's about time it was removed!
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      3467e765
    • Daniel Thompson's avatar
      ARM: 8150/3: fiq: Replace default FIQ handler · c0e7f7ee
      Daniel Thompson authored
      
      
      This patch introduces a new default FIQ handler that is structured in a
      similar way to the existing ARM exception handler and result in the FIQ
      being handled by C code running on the SVC stack (despite this code run
      in the FIQ handler is subject to severe limitations with respect to
      locking making normal interaction with the kernel impossible).
      
      This default handler allows concepts that on x86 would be handled using
      NMIs to be realized on ARM.
      
      Credit:
      
          This patch is a near complete re-write of a patch originally
          provided by Anton Vorontsov. Today only a couple of small fragments
          survive, however without Anton's work to build from this patch would
          not exist. Thanks also to Russell King for spoonfeeding me a variety
          of fixes during the review cycle.
      Signed-off-by: default avatarDaniel Thompson <daniel.thompson@linaro.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      c0e7f7ee
  7. 16 Sep, 2014 1 commit
  8. 18 Jul, 2014 1 commit
  9. 11 Apr, 2014 1 commit
  10. 11 Jan, 2014 1 commit
  11. 05 Jan, 2014 1 commit
  12. 29 Dec, 2013 1 commit
    • Russell King's avatar
      ARM: make kernel oops easier to read · ef41b5c9
      Russell King authored
      
      
      We don't need the offset for the first function name in each backtrace
      entry; this needlessly consumes screen space.  This is virtually always
      the first or second instruction in the called function.
      
      Also, recognise stmfd instructions which include r10 as a valid stack
      saving instruction, and when dumping the registers, dump six registers
      per line rather than five, and fix the wrapping.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ef41b5c9
  13. 09 Dec, 2013 1 commit
  14. 18 Nov, 2013 1 commit
  15. 19 Oct, 2013 2 commits
  16. 20 Aug, 2013 2 commits
    • Will Deacon's avatar
      ARM: cacheflush: don't bother rounding to nearest vma · 97c72d89
      Will Deacon authored
      do_cache_op finds the lowest VMA contained in the specified address
      range and rounds the range to cover only the mapped addresses.
      
      Since commit 4542b6a0
      
       ("ARM: 7365/1: drop unused parameter from
      flush_cache_user_range") the VMA is not used for anything else in this
      code and seeing as the low-level cache flushing routines return -EFAULT
      if the address is not valid, there is no need for this range truncation.
      
      This patch removes the VMA handling code from the cacheflushing syscall.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      97c72d89
    • Will Deacon's avatar
      ARM: cacheflush: split user cache-flushing into interruptible chunks · 28256d61
      Will Deacon authored
      
      
      Flushing a large, non-faulting VMA from userspace can potentially result
      in a long time spent flushing the cache line-by-line without preemption
      occurring (in the case of CONFIG_PREEMPT=n).
      
      Whilst this doesn't affect the stability of the system, it can certainly
      affect the responsiveness and CPU availability for other tasks.
      
      This patch splits up the user cacheflush code so that it flushes in
      chunks of a page. After each chunk has been flushed, we may reschedule
      if appropriate and, before processing the next chunk, we allow any
      pending signals to be handled before resuming from where we left off.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      28256d61
  17. 01 Aug, 2013 1 commit
    • Russell King's avatar
      ARM: move signal handlers into a vdso-like page · 48be69a0
      Russell King authored
      
      
      Move the signal handlers into a VDSO page rather than keeping them in
      the vectors page.  This allows us to place them randomly within this
      page, and also map the page at a random location within userspace
      further protecting these code fragments from ROP attacks.  The new
      VDSO page is also poisoned in the same way as the vector page.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      48be69a0
  18. 31 Jul, 2013 3 commits
    • Russell King's avatar
      ARM: allow kuser helpers to be removed from the vector page · f6f91b0d
      Russell King authored
      
      
      Provide a kernel configuration option to allow the kernel user helpers
      to be removed from the vector page, thereby preventing their use with
      ROP (return orientated programming) attacks.  This option is only
      visible for CPU architectures which natively support all the operations
      which kernel user helpers would normally provide, and must be enabled
      with caution.
      
      Cc: <stable@vger.kernel.org>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      f6f91b0d
    • Russell King's avatar
      ARM: move vector stubs · 19accfd3
      Russell King authored
      
      
      Move the machine vector stubs into the page above the vector page,
      which we can prevent from being visible to userspace.  Also move
      the reset stub, and place the swi vector at a location that the
      'ldr' can get to it.
      
      This hides pointers into the kernel which could give valuable
      information to attackers, and reduces the number of exploitable
      instructions at a fixed address.
      
      Cc: <stable@vger.kernel.org>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      19accfd3
    • Russell King's avatar
      ARM: poison the vectors page · f928d4f2
      Russell King authored
      
      
      Fill the empty regions of the vectors page with an exception generating
      instruction.  This ensures that any inappropriate branch to the vector
      page is appropriately trapped, rather than just encountering some code
      to execute.  (The vectors page was filled with zero before, which
      corresponds with the "andeq r0, r0, r0" instruction - a no-op.)
      
      Cc: <stable@vger.kernel.org>
      Acked-by Nicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      f928d4f2
  19. 24 Jun, 2013 1 commit
  20. 30 Apr, 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
  21. 17 Apr, 2013 1 commit
  22. 20 Jan, 2013 1 commit
  23. 07 Sep, 2012 1 commit
  24. 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
  25. 28 Jul, 2012 1 commit
  26. 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
  27. 05 Jul, 2012 1 commit
  28. 21 May, 2012 1 commit
  29. 02 May, 2012 2 commits
  30. 19 Apr, 2012 1 commit
  31. 28 Mar, 2012 1 commit
  32. 24 Mar, 2012 1 commit
  33. 09 Feb, 2012 1 commit
  34. 23 Jan, 2012 1 commit