1. 17 Apr, 2013 1 commit
  2. 03 Feb, 2013 1 commit
  3. 11 Dec, 2012 1 commit
  4. 29 Nov, 2012 1 commit
  5. 19 Nov, 2012 2 commits
  6. 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>
      68687c84
  7. 12 Oct, 2012 1 commit
  8. 01 Oct, 2012 3 commits
  9. 19 Sep, 2012 1 commit
  10. 28 Jul, 2012 4 commits
  11. 09 Jul, 2012 2 commits
  12. 21 May, 2012 2 commits
  13. 05 May, 2012 1 commit
  14. 21 Feb, 2012 1 commit
  15. 25 Jan, 2012 1 commit
    • Rabin Vincent's avatar
      ARM: 7299/1: ftrace: clear zero bit in reported IPs for Thumb-2 · d68133b5
      Rabin Vincent authored
      
      
      The dynamic ftrace ops startup test currently fails on Thumb-2 kernels:
      
       Testing tracer function: PASSED
       Testing dynamic ftrace: PASSED
       Testing dynamic ftrace ops #1: (0 0 0 0 0) FAILED!
      
      This is because while the addresses in the mcount records do not have
      the zero bit set, the IP reported by the mcount call does have it set
      (because it is copied from the LR).  This mismatch causes the ops
      filtering in ftrace_ops_list_func() to not call the relevant tracers.
      
      Fix this by clearing the zero bit before adjusting the LR for the mcount
      instruction size.  Also, combine the mov+sub into a single sub
      instruction.
      Acked-by: default avatarDave Martin <dave.martin@linaro.org>
      Signed-off-by: default avatarRabin Vincent <rabin@rab.in>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      d68133b5
  16. 17 Jan, 2012 1 commit
    • Nathaniel Husted's avatar
      Kernel: Audit Support For The ARM Platform · 29ef73b7
      Nathaniel Husted authored
      This patch provides functionality to audit system call events on the
      ARM platform. The implementation was based off the structure of the
      MIPS platform and information in this
      (http://lists.fedoraproject.org/pipermail/arm/2009-October/000382.html
      
      )
      mailing list thread. The required audit_syscall_exit and
      audit_syscall_entry checks were added to ptrace using the standard
      registers for system call values (r0 through r3). A thread information
      flag was added for auditing (TIF_SYSCALL_AUDIT) and a meta-flag was
      added (_TIF_SYSCALL_WORK) to simplify modifications to the syscall
      entry/exit. Now, if either the TRACE flag is set or the AUDIT flag is
      set, the syscall_trace function will be executed. The prober changes
      were made to Kconfig to allow CONFIG_AUDITSYSCALL to be enabled.
      
      Due to platform availability limitations, this patch was only tested
      on the Android platform running the modified "android-goldfish-2.6.29"
      kernel. A test compile was performed using Code Sourcery's
      cross-compilation toolset and the current linux-3.0 stable kernel. The
      changes compile without error. I'm hoping, due to the simple modifications,
      the patch is "obviously correct".
      Signed-off-by: default avatarNathaniel Husted <nhusted@gmail.com>
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      29ef73b7
  17. 06 Jun, 2011 1 commit
    • Ming Lei's avatar
      ARM: 6952/1: fix lockdep warning of "unannotated irqs-off" · 9fc2552a
      Ming Lei authored
      
      
      This patch fixes the lockdep warning of "unannotated irqs-off"[1].
      
      After entering __irq_usr, arm core will disable interrupt automatically,
      but __irq_usr does not annotate the irq disable, so lockdep may complain
      the warning if it has chance to check this in irq handler.
      
      This patch adds trace_hardirqs_off in __irq_usr before entering irq_handler
      to handle the irq, also calls ret_to_user_from_irq to avoid calling
      disable_irq again.
      
      This is also a fix for irq off tracer.
      
      [1], lockdep warning log of "unannotated irqs-off"
      
      [   13.804687] ------------[ cut here ]------------
      [   13.809570] WARNING: at kernel/lockdep.c:3335 check_flags+0x78/0x1d0()
      [   13.816467] Modules linked in:
      [   13.819732] Backtrace:
      [   13.822357] [<c01cb42c>] (dump_backtrace+0x0/0x100) from [<c06abb14>] (dump_stack+0x20/0x24)
      [   13.831268]  r6:c07d8c2c r5:00000d07 r4:00000000 r3:00000000
      [   13.837280] [<c06abaf4>] (dump_stack+0x0/0x24) from [<c01ffc04>] (warn_slowpath_common+0x5c/0x74)
      [   13.846649] [<c01ffba8>] (warn_slowpath_common+0x0/0x74) from [<c01ffc48>] (warn_slowpath_null+0x2c/0x34)
      [   13.856781]  r8:00000000 r7:00000000 r6:c18b8194 r5:60000093 r4:ef182000
      [   13.863708] r3:00000009
      [   13.866485] [<c01ffc1c>] (warn_slowpath_null+0x0/0x34) from [<c0237d84>] (check_flags+0x78/0x1d0)
      [   13.875823] [<c0237d0c>] (check_flags+0x0/0x1d0) from [<c023afc8>] (lock_acquire+0x4c/0x150)
      [   13.884704] [<c023af7c>] (lock_acquire+0x0/0x150) from [<c06af638>] (_raw_spin_lock+0x4c/0x84)
      [   13.893798] [<c06af5ec>] (_raw_spin_lock+0x0/0x84) from [<c01f9a44>] (sched_ttwu_pending+0x58/0x8c)
      [   13.903320]  r6:ef92d040 r5:00000003 r4:c18b8180
      [   13.908233] [<c01f99ec>] (sched_ttwu_pending+0x0/0x8c) from [<c01f9a90>] (scheduler_ipi+0x18/0x1c)
      [   13.917663]  r6:ef183fb0 r5:00000003 r4:00000000 r3:00000001
      [   13.923645] [<c01f9a78>] (scheduler_ipi+0x0/0x1c) from [<c01bc458>] (do_IPI+0x9c/0xfc)
      [   13.932006] [<c01bc3bc>] (do_IPI+0x0/0xfc) from [<c06b0888>] (__irq_usr+0x48/0xe0)
      [   13.939971] Exception stack(0xef183fb0 to 0xef183ff8)
      [   13.945281] 3fa0:                                     ffffffc3 0001500c 00000001 0001500c
      [   13.953948] 3fc0: 00000050 400b45f0 400d9000 00000000 00000001 400d9600 6474e552 bea05b3c
      [   13.962585] 3fe0: 400d96c0 bea059c0 400b6574 400b65d8 20000010 ffffffff
      [   13.969573]  r6:00000403 r5:fa240100 r4:ffffffff r3:20000010
      [   13.975585] ---[ end trace efc4896ab0fb62cb ]---
      [   13.980468] possible reason: unannotated irqs-off.
      [   13.985534] irq event stamp: 1610
      [   13.989044] hardirqs last  enabled at (1610): [<c01c703c>] no_work_pending+0x8/0x2c
      [   13.997131] hardirqs last disabled at (1609): [<c01c7024>] ret_slow_syscall+0xc/0x1c
      [   14.005371] softirqs last  enabled at (0): [<c01fe5e4>] copy_process+0x2cc/0xa24
      [   14.013183] softirqs last disabled at (0): [<  (null)>]   (null)
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      9fc2552a
  18. 24 Dec, 2010 1 commit
  19. 19 Nov, 2010 3 commits
  20. 02 Oct, 2010 1 commit
  21. 17 Sep, 2010 2 commits
    • Al Viro's avatar
      arm: fix really nasty sigreturn bug · 653d48b2
      Al Viro authored
      
      
      If a signal hits us outside of a syscall and another gets delivered
      when we are in sigreturn (e.g. because it had been in sa_mask for
      the first one and got sent to us while we'd been in the first handler),
      we have a chance of returning from the second handler to location one
      insn prior to where we ought to return.  If r0 happens to contain -513
      (-ERESTARTNOINTR), sigreturn will get confused into doing restart
      syscall song and dance.
      
      Incredible joy to debug, since it manifests as random, infrequent and
      very hard to reproduce double execution of instructions in userland
      code...
      
      The fix is simple - mark it "don't bother with restarts" in wrapper,
      i.e. set r8 to 0 in sys_sigreturn and sys_rt_sigreturn wrappers,
      suppressing the syscall restart handling on return from these guys.
      They can't legitimately return a restart-worthy error anyway.
      
      Testcase:
      	#include <unistd.h>
      	#include <signal.h>
      	#include <stdlib.h>
      	#include <sys/time.h>
      	#include <errno.h>
      
      	void f(int n)
      	{
      		__asm__ __volatile__(
      			"ldr r0, [%0]\n"
      			"b 1f\n"
      			"b 2f\n"
      			"1:b .\n"
      			"2:\n" : : "r"(&n));
      	}
      
      	void handler1(int sig) { }
      	void handler2(int sig) { raise(1); }
      	void handler3(int sig) { exit(0); }
      
      	main()
      	{
      		struct sigaction s = {.sa_handler = handler2};
      		struct itimerval t1 = { .it_value = {1} };
      		struct itimerval t2 = { .it_value = {2} };
      
      		signal(1, handler1);
      
      		sigemptyset(&s.sa_mask);
      		sigaddset(&s.sa_mask, 1);
      		sigaction(SIGALRM, &s, NULL);
      
      		signal(SIGVTALRM, handler3);
      
      		setitimer(ITIMER_REAL, &t1, NULL);
      		setitimer(ITIMER_VIRTUAL, &t2, NULL);
      
      		f(-513); /* -ERESTARTNOINTR */
      
      		write(1, "buggered\n", 9);
      		return 1;
      	}
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Acked-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      653d48b2
    • Russell King's avatar
      ARM: prevent multiple syscall restarts · b2b163bb
      Russell King authored
      
      
      Al Viro reports that calling "sys_sigsuspend(-ERESTARTNOHAND, 0, 0)"
      with two signals coming and being handled in kernel space results
      in the syscall restart being done twice.
      
      Avoid this by clearing the 'why' flag when we call the signal handling
      code to prevent further syscall restarts after the first.
      Acked-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      b2b163bb
  22. 02 Sep, 2010 4 commits
  23. 10 Aug, 2010 2 commits
  24. 11 Dec, 2009 1 commit
  25. 02 Oct, 2009 1 commit