1. 08 Nov, 2019 2 commits
  2. 30 Jul, 2018 1 commit
    • Vincent Whitchurch's avatar
      ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+ · afc9f65e
      Vincent Whitchurch authored
      When building the kernel as Thumb-2 with binutils 2.29 or newer, if the
      assembler has seen the .type directive (via ENDPROC()) for a symbol, it
      automatically handles the setting of the lowest bit when the symbol is
      used with ADR.  The badr macro on the other hand handles this lowest bit
      manually.  This leads to a jump to a wrong address in the wrong state
      in the syscall return path:
       Internal error: Oops - undefined instruction: 0 [#2] SMP THUMB2
       Modules linked in:
       CPU: 0 PID: 652 Comm: modprobe Tainted: G      D           4.18.0-rc3+ #8
       PC is at ret_fast_syscall+0x4/0x62
       LR is at sys_brk+0x109/0x128
       pc : [<80101004>]    lr : [<801c8a35>]    psr: 60000013
       Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
       Control: 50c5387d  Table: 9e82006a  DAC: 00000051
       Process modprobe (pid: 652, stack limit = 0x(ptrval))
       80101000 <ret_fast_syscall>:
       80101000:       b672            cpsid   i
       80101002:       f8d9 2008       ldr.w   r2, [r9, #8]
       80101006:       f1b2 4ffe       cmp.w   r2, #2130706432 ; 0x7f000000
       80101184 <local_restart>:
       80101184:       f8d9 a000       ldr.w   sl, [r9]
       80101188:       e92d 0030       stmdb   sp!, {r4, r5}
       8010118c:       f01a 0ff0       tst.w   sl, #240        ; 0xf0
       80101190:       d117            bne.n   801011c2 <__sys_trace>
       80101192:       46ba            mov     sl, r7
       80101194:       f5ba 7fc8       cmp.w   sl, #400        ; 0x190
       80101198:       bf28            it      cs
       8010119a:       f04f 0a00       movcs.w sl, #0
       8010119e:       f3af 8014       nop.w   {20}
       801011a2:       f2af 1ea2       subw    lr, pc, #418    ; 0x1a2
      To fix this, add a new symbol name which doesn't have ENDPROC used on it
      and use that with badr.  We can't remove the badr usage since that would
      would cause breakage with older binutils.
      Signed-off-by: default avatarVincent Whitchurch <vincent.whitchurch@axis.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
  3. 06 Jun, 2018 1 commit
    • Mathieu Desnoyers's avatar
      arm: Add syscall detection for restartable sequences · b74406f3
      Mathieu Desnoyers authored
      Syscalls are not allowed inside restartable sequences, so add a call to
      rseq_syscall() at the very beginning of system call exiting path for
      CONFIG_DEBUG_RSEQ=y kernel. This could help us to detect whether there
      is a syscall issued inside restartable sequences.
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Joel Fernandes <joelaf@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Dave Watson <davejwatson@fb.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: "H . Peter Anvin" <hpa@zytor.com>
      Cc: Chris Lameter <cl@linux.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Andrew Hunter <ahh@google.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Paul Turner <pjt@google.com>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Ben Maurer <bmaurer@fb.com>
      Cc: linux-api@vger.kernel.org
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: https://lkml.kernel.org/r/20180602124408.8430-5-mathieu.desnoyers@efficios.com
  4. 31 May, 2018 1 commit
  5. 17 Dec, 2017 1 commit
  6. 28 Sep, 2017 1 commit
  7. 17 Sep, 2017 2 commits
    • Thomas Garnier's avatar
      arm/syscalls: Optimize address limit check · e33f8d32
      Thomas Garnier authored
      Disable the generic address limit check in favor of an architecture
      specific optimized implementation. The generic implementation using
      pending work flags did not work well with ARM and alignment faults.
      The address limit is checked on each syscall return path to user-mode
      path as well as the irq user-mode return function. If the address limit
      was changed, a function is called to report data corruption (stopping
      the kernel or process based on configuration).
      The address limit check has to be done before any pending work because
      they can reset the address limit and the process is killed using a
      SIGKILL signal. For example the lkdtm address limit check does not work
      because the signal to kill the process will reset the user-mode address
      Signed-off-by: default avatarThomas Garnier <thgarnie@google.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarKees Cook <keescook@chromium.org>
      Tested-by: default avatarLeonard Crestez <leonard.crestez@nxp.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Pratyush Anand <panand@redhat.com>
      Cc: Dave Martin <Dave.Martin@arm.com>
      Cc: Will Drewry <wad@chromium.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: linux-api@vger.kernel.org
      Cc: Yonghong Song <yhs@fb.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/1504798247-48833-4-git-send-email-keescook@chromium.org
    • Thomas Garnier's avatar
      Revert "arm/syscalls: Check address limit on user-mode return" · 2404269b
      Thomas Garnier authored
      This reverts commit 73ac5d6a
      The work pending loop can call set_fs after addr_limit_user_check
      removed the _TIF_FSCHECK flag. This may happen at anytime based on how
      ARM handles alignment exceptions. It leads to an infinite loop condition.
      After discussion, it has been agreed that the generic approach is not
      tailored to the ARM architecture and any fix might not be complete. This
      patch will be replaced by an architecture specific implementation. The
      work flag approach will be kept for other architectures.
      Reported-by: default avatarLeonard Crestez <leonard.crestez@nxp.com>
      Signed-off-by: default avatarThomas Garnier <thgarnie@google.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Pratyush Anand <panand@redhat.com>
      Cc: Dave Martin <Dave.Martin@arm.com>
      Cc: Will Drewry <wad@chromium.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: linux-api@vger.kernel.org
      Cc: Yonghong Song <yhs@fb.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/1504798247-48833-3-git-send-email-keescook@chromium.org
  8. 02 Aug, 2017 4 commits
  9. 08 Jul, 2017 1 commit
    • Thomas Garnier's avatar
      arm/syscalls: Check address limit on user-mode return · 73ac5d6a
      Thomas Garnier authored
      Ensure the address limit is a user-mode segment before returning to
      user-mode. Otherwise a process can corrupt kernel-mode memory and
      elevate privileges [1].
      The set_fs function sets the TIF_SETFS flag to force a slow path on
      return. In the slow path, the address limit is checked to be USER_DS if
      The TIF_SETFS flag is added to _TIF_WORK_MASK shifting _TIF_SYSCALL_WORK
      for arm instruction immediate support. The global work mask is too big
      to used on a single instruction so adapt ret_fast_syscall.
      [1] https://bugs.chromium.org/p/project-zero/issues/detail?id=990
      Signed-off-by: default avatarThomas Garnier <thgarnie@google.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: kernel-hardening@lists.openwall.com
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Pratyush Anand <panand@redhat.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Will Drewry <wad@chromium.org>
      Cc: linux-api@vger.kernel.org
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Link: http://lkml.kernel.org/r/20170615011203.144108-2-thgarnie@google.com
  10. 18 Oct, 2016 1 commit
    • Russell King's avatar
      ARM: convert to generated system call tables · 96a8fae0
      Russell King authored
      Convert ARM to use a similar mechanism to x86 to generate the unistd.h
      system call numbers and the various kernel system call tables.  This
      means that rather than having to edit three places (asm/unistd.h for
      the total number of system calls, uapi/asm/unistd.h for the system call
      numbers, and arch/arm/kernel/calls.S for the call table) we have only
      one place to edit, making the process much more simple.
      The scripts have knowledge of the table padding requirements, so there's
      no need to worry about __NR_syscalls not fitting within the immediate
      constant field of ALU instructions anymore.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
  11. 22 Jun, 2016 1 commit
  12. 26 Aug, 2015 1 commit
    • Russell King's avatar
      ARM: entry: provide uaccess assembly macro hooks · 2190fed6
      Russell King authored
      Provide hooks into the kernel entry and exit paths to permit control
      of userspace visibility to the kernel.  The intended use is:
      - on entry to kernel from user, uaccess_disable will be called to
        disable userspace visibility
      - on exit from kernel to user, uaccess_enable will be called to
        enable userspace visibility
      - on entry from a kernel exception, uaccess_save_and_disable will be
        called to save the current userspace visibility setting, and disable
      - on exit from a kernel exception, uaccess_restore will be called to
        restore the userspace visibility as it was before the exception
      These hooks allows us to keep userspace visibility disabled for the
      vast majority of the kernel, except for localised regions where we
      want to explicitly access userspace.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  13. 25 Aug, 2015 2 commits
  14. 07 Aug, 2015 1 commit
  15. 15 May, 2015 1 commit
    • Russell King's avatar
      ARM: fix missing syscall trace exit · 1b979372
      Russell King authored
      Josh Stone reports:
        I've discovered a case where both arm and arm64 will miss a ptrace
        syscall-exit that they should report.  If the syscall is entered
        without TIF_SYSCALL_TRACE set, then it goes on the fast path.  It's
        then possible to have TIF_SYSCALL_TRACE added in the middle of the
        syscall, but ret_fast_syscall doesn't check this flag again.
      Fix this by always checking for a syscall trace in the fast exit path.
      Reported-by: default avatarJosh Stone <jistone@redhat.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  16. 08 May, 2015 1 commit
  17. 21 Nov, 2014 1 commit
  18. 26 Sep, 2014 1 commit
  19. 18 Jul, 2014 1 commit
    • Russell King's avatar
      ARM: convert all "mov.* pc, reg" to "bx reg" for ARMv6+ · 6ebbf2ce
      Russell King authored
      ARMv6 and greater introduced a new instruction ("bx") which can be used
      to return from function calls.  Recent CPUs perform better when the
      "bx lr" instruction is used rather than the "mov pc, lr" instruction,
      and this sequence is strongly recommended to be used by the ARM
      architecture manual (section A.4.1.1).
      We provide a new macro "ret" with all its variants for the condition
      code which will resolve to the appropriate instruction.
      Rather than doing this piecemeal, and miss some instances, change all
      the "mov pc" instances to use the new macro, with the exception of
      the "movs" instruction and the kprobes code.  This allows us to detect
      the "mov pc, lr" case and fix it up - and also gives us the possibility
      of deploying this for other registers depending on the CPU selection.
      Reported-by: default avatarWill Deacon <will.deacon@arm.com>
      Tested-by: Stephen Warren <swarren@nvidia.com> # Tegra Jetson TK1
      Tested-by: Robert Jarzmik <robert.jarzmik@free.fr> # mioa701_bootresume.S
      Tested-by: Andrew Lunn <andrew@lunn.ch> # Kirkwood
      Tested-by: default avatarShawn Guo <shawn.guo@freescale.com>
      Tested-by: Tony Lindgren <tony@atomide.com> # OMAPs
      Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> # Armada XP, 375, 385
      Acked-by: Sekhar Nori <nsekhar@ti.com> # DaVinci
      Acked-by: Christoffer Dall <christoffer.dall@linaro.org> # kvm/hyp
      Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com> # PXA3xx
      Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> # Xen
      Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> # ARMv7M
      Tested-by: Simon Horman <horms+renesas@verge.net.au> # Shmobile
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  20. 02 Jun, 2014 1 commit
  21. 19 Oct, 2013 1 commit
  22. 21 Sep, 2013 1 commit
  23. 22 Jul, 2013 1 commit
    • Will Deacon's avatar
      ARM: entry: allow ARM-private syscalls to be restarted · 377747c4
      Will Deacon authored
      System calls will only be restarted after signal handling if they (a)
      return an error code indicating that a restart is required and (b) have
      `why' set to a non-zero value, to indicate that the signal interrupted
      This patch leaves `why' set to a non-zero value for ARM-private syscalls
      , and only zeroes it for syscalls that are not implemented.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
  24. 17 Jun, 2013 1 commit
    • Will Deacon's avatar
      ARM: 7748/1: oabi: handle faults when loading swi instruction from userspace · 1aa2b3b7
      Will Deacon authored
      Running an OABI_COMPAT kernel on an SMP platform can lead to fun and
      games with page aging.
      If one CPU issues a swi instruction immediately before another CPU
      decides to mkold the page containing the swi instruction, then we will
      fault attempting to load the instruction during the vector_swi handler
      in order to retrieve its immediate field. Since this fault is not
      currently dealt with by our exception tables, this results in a panic:
        Unable to handle kernel paging request at virtual address 4020841c
        pgd = c490c000
        [4020841c] *pgd=84451831, *pte=bf05859d, *ppte=00000000
        Internal error: Oops: 17 [#1] PREEMPT SMP ARM
        Modules linked in: hid_sony(O)
        CPU: 1    Tainted: G        W  O  (3.4.0-perf-gf496dca-01162-gcbcc62b #1)
        PC is at vector_swi+0x28/0x88
        LR is at 0x40208420
      This patch wraps all of the swi instruction loads with the USER macro
      and provides a shared exception table entry which simply rewinds the
      saved user PC and returns from the system call (without setting tbl, so
      there's no worries with tracing or syscall restarting). Returning to
      userspace will re-enter the page fault handler, from where we will
      probably send SIGSEGV to the current task.
      Reported-by: default avatarWang, Yalin <yalin.wang@sonymobile.com>
      Reviewed-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  25. 17 Apr, 2013 1 commit
  26. 03 Apr, 2013 3 commits
    • Kevin Hilman's avatar
      ARM: 7688/1: add support for context tracking subsystem · b0088480
      Kevin Hilman authored
      commit 91d1aa43
       (context_tracking: New context tracking susbsystem)
      generalized parts of the RCU userspace extended quiescent state into
      the context tracking subsystem.  Context tracking is then used
      to implement adaptive tickless (a.k.a extended nohz)
      To support the new context tracking subsystem on ARM, the user/kernel
      boundary transtions need to be instrumented.
      For exceptions and IRQs in usermode, the existing usr_entry macro is
      used to instrument the user->kernel transition.  For the return to
      usermode path, the ret_to_user* path is instrumented.  Using the
      usr_entry macro, this covers interrupts in userspace, data abort and
      prefetch abort exceptions in userspace as well as undefined exceptions
      in userspace (which is where FP emulation and VFP are handled.)
      For syscalls, the slow return path is covered by instrumenting the
      ret_to_user path.  In addition, the syscall entry point is
      instrumented which covers the user->kernel transition for both fast
      and slow syscalls, and an additional instrumentation point is added
      for the fast syscall return path (ret_fast_syscall).
      Cc: Mats Liljegren <mats.liljegren@enea.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: default avatarKevin Hilman <khilman@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
    • Russell King's avatar
      ARM: entry-common: get rid of unnecessary ifdefs · 651e9499
      Russell King authored
      The contents of the asm_trace_hardirqs_on is already conditional on
      CONFIG_TRACE_IRQFLAGS.  There's little point also making the use
      of the macro conditional as well.  Get rid of these ifdefs to make
      the code easier to read.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
    • Rabin Vincent's avatar
      ARM: 7689/1: add unwind annotations to ftrace asm · b21e023b
      Rabin Vincent authored
      Add unwind annotations to the ftrace assembly code so that the function
      tracer's stacktracing options (func_stack_trace, etc.) work when
      CONFIG_ARM_UNWIND is enabled.
      Signed-off-by: default avatarRabin Vincent <rabin@rab.in>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  27. 03 Feb, 2013 1 commit
  28. 11 Dec, 2012 1 commit
  29. 29 Nov, 2012 1 commit
  30. 19 Nov, 2012 2 commits
  31. 15 Oct, 2012 1 commit
    • Russell King's avatar
      ARM: fix oops on initial entry to userspace with Thumb2 kernels · 68687c84
      Russell King authored
      Daniel Mack reports an oops at boot with the latest kernels:
        Internal error: Oops - undefined instruction: 0 [#1] SMP THUMB2
        Modules linked in:
        CPU: 0    Not tainted  (3.6.0-11057-g584df1d #145)
        PC is at cpsw_probe+0x45a/0x9ac
        LR is at trace_hardirqs_on_caller+0x8f/0xfc
        pc : [<c03493de>]    lr : [<c005e81f>]    psr: 60000113
        sp : cf055fb0  ip : 00000000  fp : 00000000
        r10: 00000000  r9 : 00000000  r8 : 00000000
        r7 : 00000000  r6 : 00000000  r5 : c0344555  r4 : 00000000
        r3 : cf057a40  r2 : 00000000  r1 : 00000001  r0 : 00000000
        Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment user
        Control: 50c5387d  Table: 8f3f4019  DAC: 00000015
        Process init (pid: 1, stack limit = 0xcf054240)
        Stack: (0xcf055fb0 to 0xcf056000)
        5fa0:                                     00000001 00000000 00000000 00000000
        5fc0: cf055fb0 c000d1a8 00000000 00000000 00000000 00000000 00000000 00000000
        5fe0: 00000000 be9b3f10 00000000 b6f6add0 00000010 00000000 aaaabfaf a8babbaa
      The analysis of this is as follows.  In init/main.c, we issue:
      	kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
      This creates a new thread, which falls through to the ret_from_fork
      assembly, with r4 set NULL and r5 set to kernel_init.  You can see
      this in your oops dump register set - r5 is 0xc0344555, which is the
      address of kernel_init plus 1 which marks the function as Thumb code.
      Now, let's look at this code a little closer - this is what the
      disassembly looks like:
        c000d180 <ret_from_fork>:
        c000d180:       f03a fe08       bl      c0047d94 <schedule_tail>
        c000d184:       2d00            cmp     r5, #0
        c000d186:       bf1e            ittt    ne
        c000d188:       4620            movne   r0, r4
        c000d18a:       46fe            movne   lr, pc <-- XXXXXXX
        c000d18c:       46af            movne   pc, r5
        c000d18e:       46e9            mov     r9, sp
        c000d190:       ea4f 3959       mov.w   r9, r9, lsr #13
        c000d194:       ea4f 3949       mov.w   r9, r9, lsl #13
        c000d198:       e7c8            b.n     c000d12c <ret_to_user>
        c000d19a:       bf00            nop
        c000d19c:       f3af 8000       nop.w
      This code was introduced in 9fff2fa0
       (arm: switch to saner
      kernel_execve() semantics).  I have marked one instruction, and it's
      the significant one - I'll come back to that later.
      Eventually, having had a successful call to kernel_execve(), kernel_init()
      returns zero.
      In returning, it uses the value in 'lr' which was set by the instruction
      I marked above.  Unfortunately, this causes lr to contain 0xc000d18e -
      an even address.  This switches the ISA to ARM on return but with a non
      word aligned PC value.
      So, what do we end up executing?  Well, not the instructions above - yes
      the opcodes, but they don't mean the same thing in ARM mode.  In ARM mode,
      it looks like this instead:
        c000d18c:       46e946af        strbtmi r4, [r9], pc, lsr #13
        c000d190:       3959ea4f        ldmdbcc r9, {r0, r1, r2, r3, r6, r9, fp, sp, lr, pc}^
        c000d194:       3949ea4f        stmdbcc r9, {r0, r1, r2, r3, r6, r9, fp, sp, lr, pc}^
        c000d198:       bf00e7c8        svclt   0x0000e7c8
        c000d19c:       8000f3af        andhi   pc, r0, pc, lsr #7
        c000d1a0:       e88db092        stm     sp, {r1, r4, r7, ip, sp, pc}
        c000d1a4:       46e81fff                        ; <UNDEFINED> instruction: 0x46e81fff
        c000d1a8:       8a00f3ef        bhi     0xc004a16c
        c000d1ac:       0a0cf08a        beq     0xc03493dc
      I have included more above, because it's relevant.  The PSR flags which
      we can see in the oops dump are nZCv, so Z and C are set.
      All the above ARM instructions are not executed, except for two.
      c000d1a0, which has no writeback, and writes below the current stack
      pointer (and that data is lost when we take the next exception.) The
      other instruction which is executed is c000d1ac, which takes us to...
      0xc03493dc.  However, remember that bit 1 of the PC got set.  So that
      makes the PC value 0xc03493de.
      And that value is the value we find in the oops dump for PC.  What is
      the instruction here when interpreted in ARM mode?
             0:       f71e150c                ; <UNDEFINED> instruction: 0xf71e150c
      and there we have our undefined instruction (remember that the 'never'
      condition code, 0xf, has been deprecated and is now always executed as
      it is now being used for additional instructions.)
      This path also nicely explains the state of the stack we see in the oops
      dump too.
      The above is a consistent and sane story for how we got to the oops
      dump, which all stems from the instruction at 0xc000d18a being wrong.
      Reported-by: default avatarDaniel Mack <zonque@gmail.com>
      Tested-by: default avatarDaniel Mack <zonque@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>