1. 31 Jul, 2012 7 commits
    • Javier Martinez Canillas's avatar
      ARM: 7480/1: only call smp_send_stop() on SMP · c5dff4ff
      Javier Martinez Canillas authored
      On reboot or poweroff (machine_shutdown()) a call to smp_send_stop() is
      made (to stop the others CPU's) when CONFIG_SMP=y.
      
      arch/arm/kernel/process.c:
      
      void machine_shutdown(void)
      {
       #ifdef CONFIG_SMP
             smp_send_stop();
       #endif
      }
      
      smp_send_stop() calls the function pointer smp_cross_call(), which is set
      on the smp_init_cpus() function for OMAP processors.
      
      arch/arm/mach-omap2/omap-smp.c:
      
      void __init smp_init_cpus(void)
      {
      ...
      	set_smp_cross_call(gic_raise_softirq);
      ...
      }
      
      But the ARM setup_arch() function only calls smp_init_cpus()
      if CONFIG_SMP=y && is_smp().
      
      arm/kernel/setup.c:
      
      void __init setup_arch(char **cmdline_p)
      {
      ...
       #ifdef CONFIG_SMP
      	if (is_smp())
      		smp_init_cpus();
       #endif
      ...
      }
      
      Newer OMAP CPU's are SMP machines so omap2plus_defconfig sets
      CONFIG_SMP=y. Unfortunately on an OMAP UP machine is_smp()
      returns false and smp_init_cpus() is never called and the
      smp_cross_call() function remains NULL.
      
      If the machine is rebooted or powered off, smp_send_stop() will
      be called (since CONFIG_SMP=y) leading to the following error:
      
      [   42.815551] Restarting system.
      [   42.819030] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      [   42.827667] pgd = d7a74000
      [   42.830566] [00000000] *pgd=96ce7831, *pte=00000000, *ppte=00000000
      [   42.837249] Internal error: Oops: 80000007 [#1] SMP ARM
      [   42.842773] Modules linked in:
      [   42.846008] CPU: 0    Not tainted  (3.5.0-rc3-next-20120622-00002-g62e87ba-dirty #44)
      [   42.854278] PC is at 0x0
      [   42.856994] LR is at smp_send_stop+0x4c/0xe4
      [   42.861511] pc : [<00000000>]    lr : [<c00183a4>]    psr: 60000013
      [   42.861511] sp : d6c85e70  ip : 00000000  fp : 00000000
      [   42.873626] r10: 00000000  r9 : d6c84000  r8 : 00000002
      [   42.879150] r7 : c07235a0  r6 : c06dd2d0  r5 : 000f4241  r4 : d6c85e74
      [   42.886047] r3 : 00000000  r2 : 00000000  r1 : 00000006  r0 : d6c85e74
      [   42.892944] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      [   42.900482] Control: 10c5387d  Table: 97a74019  DAC: 00000015
      [   42.906555] Process reboot (pid: 1166, stack limit = 0xd6c842f8)
      [   42.912902] Stack: (0xd6c85e70 to 0xd6c86000)
      [   42.917510] 5e60:                                     c07235a0 00000000 00000000 d6c84000
      [   42.926177] 5e80: 01234567 c00143d0 4321fedc c00511bc d6c85ebc 00000168 00000460 00000000
      [   42.934814] 5ea0: c1017950 a0000013 c1017900 d8014390 d7ec3858 c0498e48 c1017950 00000000
      [   42.943481] 5ec0: d6ddde10 d6c85f78 00000003 00000000 d6ddde10 d6c84000 00000000 00000000
      [   42.952117] 5ee0: 00000002 00000000 00000000 c0088c88 00000002 00000000 00000000 c00f4b90
      [   42.960784] 5f00: 00000000 d6c85ebc d8014390 d7e311c8 60000013 00000103 00000002 d6c84000
      [   42.969421] 5f20: c00f3274 d6e00a00 00000001 60000013 d6c84000 00000000 00000000 c00895d4
      [   42.978057] 5f40: 00000002 d8007c80 d781f000 c00f6150 d8010cc0 c00f3274 d781f000 d6c84000
      [   42.986694] 5f60: c0013020 d6e00a00 00000001 20000010 0001257c ef000000 00000000 c00895d4
      [   42.995361] 5f80: 00000002 00000001 00000003 00000000 00000001 00000003 00000000 00000058
      [   43.003997] 5fa0: c00130c8 c0012f00 00000001 00000003 fee1dead 28121969 01234567 00000002
      [   43.012634] 5fc0: 00000001 00000003 00000000 00000058 00012584 0001257c 00000001 00000000
      [   43.021270] 5fe0: 000124bc bec5cc6c 00008f9c 4a2f7c40 20000010 fee1dead 00000000 00000000
      [   43.029968] [<c00183a4>] (smp_send_stop+0x4c/0xe4) from [<c00143d0>] (machine_restart+0xc/0x4c)
      [   43.039154] [<c00143d0>] (machine_restart+0xc/0x4c) from [<c00511bc>] (sys_reboot+0x144/0x1f0)
      [   43.048278] [<c00511bc>] (sys_reboot+0x144/0x1f0) from [<c0012f00>] (ret_fast_syscall+0x0/0x3c)
      [   43.057464] Code: bad PC value
      [   43.060760] ---[ end trace c3988d1dd0b8f0fb ]---
      
      Add a check so smp_cross_call() is only called when there is more than one CPU on-line.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: Javier Martinez Canillas <javier at dowhile0.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      c5dff4ff
    • Will Deacon's avatar
      ARM: 7478/1: errata: extend workaround for erratum #720789 · 5a783cbc
      Will Deacon authored
      Commit cdf357f1 ("ARM: 6299/1: errata: TLBIASIDIS and TLBIMVAIS
      operations can broadcast a faulty ASID") replaced by-ASID TLB flushing
      operations with all-ASID variants to workaround A9 erratum #720789.
      
      This patch extends the workaround to include the tlb_range operations,
      which were overlooked by the original patch.
      
      Cc: <stable@vger.kernel.org>
      Tested-by: default avatarSteve Capper <steve.capper@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      5a783cbc
    • Colin Cross's avatar
      ARM: 7477/1: vfp: Always save VFP state in vfp_pm_suspend on UP · 24b35521
      Colin Cross authored
      vfp_pm_suspend should save the VFP state in suspend after
      any lazy context switch.  If it only saves when the VFP is enabled,
      the state can get lost when, on a UP system:
        Thread 1 uses the VFP
        Context switch occurs to thread 2, VFP is disabled but the
           VFP context is not saved
        Thread 2 initiates suspend
        vfp_pm_suspend is called with the VFP disabled, and the unsaved
           VFP context of Thread 1 in the registers
      
      Modify vfp_pm_suspend to save the VFP context whenever
      vfp_current_hw_state is not NULL.
      
      Includes a fix from Ido Yariv <ido@wizery.com>, who pointed out that on
      SMP systems, the state pointer can be pointing to a freed task struct if
      a task exited on another cpu, fixed by using #ifndef CONFIG_SMP in the
      new if clause.
      
      Cc: Barry Song <bs14@csr.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Ido Yariv <ido@wizery.com>
      Cc: Daniel Drake <dsd@laptop.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarColin Cross <ccross@android.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      24b35521
    • Colin Cross's avatar
      ARM: 7476/1: vfp: only clear vfp state for current cpu in vfp_pm_suspend · a84b895a
      Colin Cross authored
      vfp_pm_suspend runs on each cpu, only clear the hardware state
      pointer for the current cpu.  Prevents a possible crash if one
      cpu clears the hw state pointer when another cpu has already
      checked if it is valid.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarColin Cross <ccross@android.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      a84b895a
    • Colin Cross's avatar
      ARM: 7468/1: ftrace: Trace function entry before updating index · 4c36595e
      Colin Cross authored
      Commit 722b3c74 modified x86 ftrace to
      avoid tracing all functions called from irqs when function graph was
      used with a filter.  Port the same fix to ARM.
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarColin Cross <ccross@android.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      4c36595e
    • Will Deacon's avatar
      ARM: 7467/1: mutex: use generic xchg-based implementation for ARMv6+ · a76d7bd9
      Will Deacon authored
      The open-coded mutex implementation for ARMv6+ cores suffers from a
      severe lack of barriers, so in the uncontended case we don't actually
      protect any accesses performed during the critical section.
      
      Furthermore, the code is largely a duplication of the ARMv6+ atomic_dec
      code but optimised to remove a branch instruction, as the mutex fastpath
      was previously inlined. Now that this is executed out-of-line, we can
      reuse the atomic access code for the locking (in fact, we use the xchg
      code as this produces shorter critical sections).
      
      This patch uses the generic xchg based implementation for mutexes on
      ARMv6+, which introduces barriers to the lock/unlock operations and also
      has the benefit of removing a fair amount of inline assembly code.
      
      Cc: <stable@vger.kernel.org>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Reported-by: default avatarShan Kang <kangshan0910@gmail.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      a76d7bd9
    • Shawn Guo's avatar
      ARM: 7466/1: disable interrupt before spinning endlessly · 98bd8b96
      Shawn Guo authored
      The CPU will endlessly spin at the end of machine_halt and
      machine_restart calls.  However, this will lead to a soft lockup
      warning after about 20 seconds, if CONFIG_LOCKUP_DETECTOR is enabled,
      as system timer is still alive.
      
      Disable interrupt before going to spin endlessly, so that the lockup
      warning will never be seen.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarMarek Vasut <marex@denx.de>
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      98bd8b96
  2. 29 Jul, 2012 1 commit
  3. 09 Jul, 2012 1 commit
    • Stephen Boyd's avatar
      ARM: 7457/1: smp: Fix suspicious RCU originating from cpu_die() · ff081e05
      Stephen Boyd authored
      While running hotplug tests I ran into this RCU splat
      
      ===============================
      [ INFO: suspicious RCU usage. ]
      3.4.0 #3275 Tainted: G        W
      -------------------------------
      include/linux/rcupdate.h:729 rcu_read_lock() used illegally while idle!
      
      other info that might help us debug this:
      
      RCU used illegally from idle CPU!
      rcu_scheduler_active = 1, debug_locks = 0
      RCU used illegally from extended quiescent state!
      4 locks held by swapper/2/0:
       #0:  ((cpu_died).wait.lock){......}, at: [<c00ab128>] complete+0x1c/0x5c
       #1:  (&p->pi_lock){-.-.-.}, at: [<c00b275c>] try_to_wake_up+0x2c/0x388
       #2:  (&rq->lock){-.-.-.}, at: [<c00b2860>] try_to_wake_up+0x130/0x388
       #3:  (rcu_read_lock){.+.+..}, at: [<c00abe5c>] cpuacct_charge+0x28/0x1f4
      
      stack backtrace:
      [<c001521c>] (unwind_backtrace+0x0/0x12c) from [<c00abec8>] (cpuacct_charge+0x94/0x1f4)
      [<c00abec8>] (cpuacct_charge+0x94/0x1f4) from [<c00b395c>] (update_curr+0x24c/0x2c8)
      [<c00b395c>] (update_curr+0x24c/0x2c8) from [<c00b59c4>] (enqueue_task_fair+0x50/0x194)
      [<c00b59c4>] (enqueue_task_fair+0x50/0x194) from [<c00afea4>] (enqueue_task+0x30/0x34)
      [<c00afea4>] (enqueue_task+0x30/0x34) from [<c00b0908>] (ttwu_activate+0x14/0x38)
      [<c00b0908>] (ttwu_activate+0x14/0x38) from [<c00b28a8>] (try_to_wake_up+0x178/0x388)
      [<c00b28a8>] (try_to_wake_up+0x178/0x388) from [<c00a82a0>] (__wake_up_common+0x34/0x78)
      [<c00a82a0>] (__wake_up_common+0x34/0x78) from [<c00ab154>] (complete+0x48/0x5c)
      [<c00ab154>] (complete+0x48/0x5c) from [<c07db7cc>] (cpu_die+0x2c/0x58)
      [<c07db7cc>] (cpu_die+0x2c/0x58) from [<c000f954>] (cpu_idle+0x64/0xfc)
      [<c000f954>] (cpu_idle+0x64/0xfc) from [<80208160>] (0x80208160)
      
      When a cpu is marked offline during its idle thread it calls
      cpu_die() during an RCU idle period. cpu_die() calls complete()
      to notify the killing process that the cpu has died. complete()
      calls into the scheduler code and eventually grabs an RCU read
      lock in cpuacct_charge().
      
      Mark complete() as RCU_NONIDLE so that RCU pays attention to this
      CPU for the duration of the complete() function even though it's
      in idle.
      Suggested-by: default avatar"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ff081e05
  4. 08 Jul, 2012 3 commits
  5. 07 Jul, 2012 2 commits
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm · cd6407fe
      Linus Torvalds authored
      Pull ARM fixes from Russell King:
       "Last merge window, we had some updates from Al cleaning up the signal
        restart handling.  These have caused some problems on ARM, and while
        Al has some fixes, we have some concerns with Al's patches but we've
        been unsuccesful with discussing this.
      
        We have got to the point where we need to do something, and we've
        decided that the best solution is to revert the appropriate commits
        until Al is able to reply to us.
      
        Also included here are four patches to fix warnings that I've noticed
        in my build system, and one fix for kprobes test code."
      
      * 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
        ARM: fix warning caused by wrongly typed arm_dma_limit
        ARM: fix warnings about atomic64_read
        ARM: 7440/1: kprobes: only test 'sub pc, pc, #1b-2b+8-2' on ARMv6
        ARM: 7441/1: perf: return -EOPNOTSUPP if requested mode exclusion is unavailable
        ARM: 7443/1: Revert "new way of handling ERESTART_RESTARTBLOCK"
        ARM: 7442/1: Revert "remove unused restart trampoline"
        ARM: fix set_domain() macro
        ARM: fix mach-versatile/pci.c warning
      cd6407fe
    • Andy Lutomirski's avatar
      security: Minor improvements to no_new_privs documentation · c540521b
      Andy Lutomirski authored
      The documentation didn't actually mention how to enable no_new_privs.
      This also adds a note about possible interactions between
      no_new_privs and LSMs (i.e. why teaching systemd to set no_new_privs
      is not necessarily a good idea), and it references the new docs
      from include/linux/prctl.h.
      Suggested-by: default avatarRob Landley <rob@landley.net>
      Signed-off-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      c540521b
  6. 06 Jul, 2012 11 commits
  7. 05 Jul, 2012 15 commits