1. 21 Aug, 2015 1 commit
    • Russell King's avatar
      ARM: domains: switch to keeping domain value in register · 1eef5d2f
      Russell King authored
      
      
      Rather than modifying both the domain access control register and our
      per-thread copy, modify only the domain access control register, and
      use the per-thread copy to save and restore the register over context
      switches.  We can also avoid the explicit initialisation of the
      init thread_info structure.
      
      This allows us to avoid needing to gain access to the thread information
      at the uaccess control sites.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      1eef5d2f
  2. 02 Apr, 2015 2 commits
    • Russell King's avatar
      ARM: move reboot code to arch/arm/kernel/reboot.c · 045ab94e
      Russell King authored
      
      
      Move shutdown and reboot related code to a separate file, out of
      process.c.  This helps to avoid polluting process.c with non-process
      related code.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      045ab94e
    • Russell King's avatar
      ARM: fix broken hibernation · 767bf7e7
      Russell King authored
      Normally, when a CPU wants to clear a cache line to zero in the external
      L2 cache, it would generate bus cycles to write each word as it would do
      with any other data access.
      
      However, a Cortex A9 connected to a L2C-310 has a specific feature where
      the CPU can detect this operation, and signal that it wants to zero an
      entire cache line.  This feature, known as Full Line of Zeros (FLZ),
      involves a non-standard AXI signalling mechanism which only the L2C-310
      can properly interpret.
      
      There are separate enable bits in both the L2C-310 and the Cortex A9 -
      the L2C-310 needs to be enabled and have the FLZ enable bit set in the
      auxiliary control register before the Cortex A9 has this feature
      enabled.
      
      Unfortunately, the suspend code was not respecting this - it's not
      obvious from the code:
      
      swsusp_arch_suspend()
       cpu_suspend() /* saves the Cortex A9 auxiliary control register */
        arch_save_image()
        soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */
         cpu_resume() /* restores the Cortex A9 registers, inc auxcr */
      
      At this point, we end up with the L2C disabled, but the Cortex A9 with
      FLZ enabled - which means any memset() or zeroing of a full cache line
      will fail to take effect.
      
      A similar issue exists in the resume path, but it's slightly more
      complex:
      
      swsusp_arch_suspend()
       cpu_suspend() /* saves the Cortex A9 auxiliary control register */
        arch_save_image() /* image with A9 auxcr saved */
      ...
      swsusp_arch_resume()
       call_with_stack()
        arch_restore_image() /* restores image with A9 auxcr saved above */
        soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */
         cpu_resume() /* restores the Cortex A9 registers, inc auxcr */
      
      Again, here we end up with the L2C disabled, but Cortex A9 FLZ enabled.
      
      There's no need to turn off the L2C in either of these two paths; there
      are benefits from not doing so - for example, the page copies will be
      faster with the L2C enabled.
      
      Hence, fix this by providing a variant of soft_restart() which can be
      used without turning the L2 cache controller off, and use it in both
      of these paths to keep the L2C enabled across the respective resume
      transitions.
      
      Fixes: 8ef418c7
      
       ("ARM: l2c: trial at enabling some Cortex-A9 optimisations")
      Reported-by: default avatarSean Cross <xobs@kosagi.com>
      Tested-by: default avatarSean Cross <xobs@kosagi.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      767bf7e7
  3. 27 Mar, 2015 1 commit
    • Nathan Lynch's avatar
      ARM: 8331/1: VDSO initialization, mapping, and synchronization · ecf99a43
      Nathan Lynch authored
      
      
      Initialize the VDSO page list at boot, install the VDSO mapping at
      exec time, and update the data page during timer ticks.  This code is
      not built if CONFIG_VDSO is not enabled.
      
      Account for the VDSO length when randomizing the offset from the
      stack.  The [vdso] and [vvar] pages are placed immediately following
      the sigpage with separate _install_special_mapping calls.
      
      We want to "penalize" systems lacking the arch timer as little
      as possible.  Previous versions of this code installed the VDSO
      unconditionally and unmodified, making it a measurably slower way for
      glibc to invoke the real syscalls on such systems.  E.g. calling
      gettimeofday via glibc goes from ~560ns to ~630ns on i.MX6Q.
      
      If we can indicate to glibc that the time-related APIs in the VDSO are
      not accelerated, glibc can continue to invoke the syscalls directly
      instead of dispatching through the VDSO only to fall back to the slow
      path.
      
      Thus, if the architected timer is unusable for whatever reason, patch
      the VDSO at boot time so that symbol lookups for gettimeofday and
      clock_gettime return NULL.  (This is similar to what powerpc does and
      borrows code from there.)  This allows glibc to perform the syscall
      directly instead of passing control to the VDSO, which minimizes the
      penalty.  In my measurements the time taken for a gettimeofday call
      via glibc goes from ~560ns to ~580ns (again on i.MX6Q), and this is
      solely due to adding a test and branch to glibc's gettimeofday syscall
      wrapper.
      
      An alternative to patching the VDSO at boot would be to not install
      the VDSO at all when the arch timer isn't usable.  Another alternative
      is to include a separate "dummy" vdso.so without gettimeofday and
      clock_gettime, which would be selected at boot time.  Either of these
      would get cumbersome if the VDSO were to gain support for an API such
      as getcpu which is unrelated to arch timer support.
      Signed-off-by: default avatarNathan Lynch <nathan_lynch@mentor.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ecf99a43
  4. 03 Dec, 2014 1 commit
  5. 26 Sep, 2014 4 commits
  6. 17 Sep, 2014 1 commit
  7. 16 Sep, 2014 1 commit
  8. 08 Apr, 2014 1 commit
    • Russell King's avatar
      ARM: add missing system_misc.h include to process.c · 779dd959
      Russell King authored
      
      
      arm_pm_restart(), arm_pm_idle() and soft_restart() are all declared in
      system_misc.h, but this file is not included in process.c.  Add this
      missing include.  Found via sparse:
      
      arch/arm/kernel/process.c:98:6: warning: symbol 'soft_restart' was not declared. Should it be static?
      arch/arm/kernel/process.c:127:6: warning: symbol 'arm_pm_restart' was not declared. Should it be static?
      arch/arm/kernel/process.c:134:6: warning: symbol 'arm_pm_idle' was not declared. Should it be static?
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      779dd959
  9. 07 Apr, 2014 1 commit
  10. 11 Feb, 2014 1 commit
  11. 03 Feb, 2014 1 commit
  12. 09 Dec, 2013 1 commit
  13. 07 Aug, 2013 1 commit
  14. 03 Aug, 2013 1 commit
    • Russell King's avatar
      ARM: fix a cockup in 48be69a0 (ARM: move signal handlers into a vdso-like page) · e0d40756
      Russell King authored
      Unfortunately, I never committed the fix to a nasty oops which can
      occur as a result of that commit:
      
      ------------[ cut here ]------------
      kernel BUG at /home/olof/work/batch/include/linux/mm.h:414!
      Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
      Modules linked in:
      CPU: 0 PID: 490 Comm: killall5 Not tainted 3.11.0-rc3-00288-gabe03080
      
       #53
      task: e90acac0 ti: e9be8000 task.ti: e9be8000
      PC is at special_mapping_fault+0xa4/0xc4
      LR is at __do_fault+0x68/0x48c
      
      This doesn't show up unless you do quite a bit of testing; a simple
      boot test does not do this, so all my nightly tests were passing fine.
      
      The reason for this is that install_special_mapping() expects the
      page array to stick around, and as this was only inserting one page
      which was stored on the kernel stack, that's why this was blowing up.
      Reported-by: default avatarOlof Johansson <olof@lixom.net>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      e0d40756
  15. 01 Aug, 2013 3 commits
  16. 09 Jul, 2013 3 commits
  17. 24 Jun, 2013 1 commit
  18. 17 Jun, 2013 1 commit
    • Stephen Warren's avatar
      ARM: 7759/1: decouple CPU offlining from reboot/shutdown · 19ab428f
      Stephen Warren authored
      
      
      Add comments to machine_shutdown()/halt()/power_off()/restart() that
      describe their purpose and/or requirements re: CPUs being active/not.
      
      In machine_shutdown(), replace the call to smp_send_stop() with a call to
      disable_nonboot_cpus(). This completely disables all but one CPU, thus
      satisfying the requirement that only a single CPU be active for kexec.
      Adjust Kconfig dependencies for this change.
      
      In machine_halt()/power_off()/restart(), call smp_send_stop() directly,
      rather than via machine_shutdown(); these functions don't need to
      completely de-activate all CPUs using hotplug, but rather just quiesce
      them.
      
      Remove smp_kill_cpus(), and its call from smp_send_stop().
      smp_kill_cpus() was indirectly calling smp_ops.cpu_kill() without calling
      smp_ops.cpu_die() on the target CPUs first. At least some implementations
      of smp_ops had issues with this; it caused cpu_kill() to hang on Tegra,
      for example. Since smp_send_stop() is only used for shutdown, halt, and
      power-off, there is no need to attempt any kind of CPU hotplug here.
      
      Adjust Kconfig to reflect that machine_shutdown() (and hence kexec)
      relies upon disable_nonboot_cpus(). However, this alone doesn't guarantee
      that hotplug will work, or even that hotplug is implemented for a
      particular piece of HW that a multi-platform zImage runs on. Hence, add
      error-checking to machine_kexec() to determine whether it did work.
      Suggested-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: Stephen Warren's avatarStephen Warren <swarren@nvidia.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Tested-by: default avatarZhangfei Gao <zhangfei.gao@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      19ab428f
  19. 22 May, 2013 1 commit
    • Steven Capper's avatar
      ARM: 7727/1: remove the .vm_mm value from gate_vma · 4ca46c5e
      Steven Capper authored
      If one reads /proc/$PID/smaps, the mmap_sem belonging to the
      address space of the task being examined is locked for reading.
      All the pages of the vmas belonging to the task's address space
      are then walked with this lock held.
      
      If a gate_vma is present in the architecture, it too is examined
      by the fs/proc/task_mmu.c code. As gate_vma doesn't belong to the
      address space of the task though, its pages are not walked.
      
      A recent cleanup (commit f6604efe
      
      ) of the gate_vma initialisation
      code set the vm_mm value to &init_mm. Unfortunately a non-NULL
      vm_mm value in the gate_vma will cause the task_mmu code to attempt
      to walk the pages of the gate_vma (with no mmap-sem lock held). If
      one enables Transparent Huge Page support and vm debugging, this
      will then cause OOPses as pmd_trans_huge_lock is called without
      mmap_sem being locked.
      
      This patch removes the .vm_mm value from gate_vma, restoring the
      original behaviour of the task_mmu code.
      Signed-off-by: default avatarSteve Capper <steve.capper@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      4ca46c5e
  20. 01 May, 2013 1 commit
    • Tejun Heo's avatar
      dump_stack: unify debug information printed by show_regs() · a43cb95d
      Tejun Heo authored
      
      
      show_regs() is inherently arch-dependent but it does make sense to print
      generic debug information and some archs already do albeit in slightly
      different forms.  This patch introduces a generic function to print debug
      information from show_regs() so that different archs print out the same
      information and it's much easier to modify what's printed.
      
      show_regs_print_info() prints out the same debug info as dump_stack()
      does plus task and thread_info pointers.
      
      * Archs which didn't print debug info now do.
      
        alpha, arc, blackfin, c6x, cris, frv, h8300, hexagon, ia64, m32r,
        metag, microblaze, mn10300, openrisc, parisc, score, sh64, sparc,
        um, xtensa
      
      * Already prints debug info.  Replaced with show_regs_print_info().
        The printed information is superset of what used to be there.
      
        arm, arm64, avr32, mips, powerpc, sh32, tile, unicore32, x86
      
      * s390 is special in that it used to print arch-specific information
        along with generic debug info.  Heiko and Martin think that the
        arch-specific extra isn't worth keeping s390 specfic implementation.
        Converted to use the generic version.
      
      Note that now all archs print the debug info before actual register
      dumps.
      
      An example BUG() dump follows.
      
       kernel BUG at /work/os/work/kernel/workqueue.c:4841!
       invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
       Modules linked in:
       CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.9.0-rc1-work+ #7
       Hardware name: empty empty/S3992, BIOS 080011  10/26/2007
       task: ffff88007c85e040 ti: ffff88007c860000 task.ti: ffff88007c860000
       RIP: 0010:[<ffffffff8234a07e>]  [<ffffffff8234a07e>] init_workqueues+0x4/0x6
       RSP: 0000:ffff88007c861ec8  EFLAGS: 00010246
       RAX: ffff88007c861fd8 RBX: ffffffff824466a8 RCX: 0000000000000001
       RDX: 0000000000000046 RSI: 0000000000000001 RDI: ffffffff8234a07a
       RBP: ffff88007c861ec8 R08: 0000000000000000 R09: 0000000000000000
       R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff8234a07a
       R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
       FS:  0000000000000000(0000) GS:ffff88007dc00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: ffff88015f7ff000 CR3: 00000000021f1000 CR4: 00000000000007f0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
       Stack:
        ffff88007c861ef8 ffffffff81000312 ffffffff824466a8 ffff88007c85e650
        0000000000000003 0000000000000000 ffff88007c861f38 ffffffff82335e5d
        ffff88007c862080 ffffffff8223d8c0 ffff88007c862080 ffffffff81c47760
       Call Trace:
        [<ffffffff81000312>] do_one_initcall+0x122/0x170
        [<ffffffff82335e5d>] kernel_init_freeable+0x9b/0x1c8
        [<ffffffff81c47760>] ? rest_init+0x140/0x140
        [<ffffffff81c4776e>] kernel_init+0xe/0xf0
        [<ffffffff81c6be9c>] ret_from_fork+0x7c/0xb0
        [<ffffffff81c47760>] ? rest_init+0x140/0x140
        ...
      
      v2: Typo fix in x86-32.
      
      v3: CPU number dropped from show_regs_print_info() as
          dump_stack_print_info() has been updated to print it.  s390
          specific implementation dropped as requested by s390 maintainers.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarJesper Nilsson <jesper.nilsson@axis.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Acked-by: Chris Metcalf <cmetcalf@tilera.com>		[tile bits]
      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>
      a43cb95d
  21. 08 Apr, 2013 2 commits
  22. 13 Mar, 2013 1 commit
  23. 23 Feb, 2013 1 commit
  24. 18 Feb, 2013 1 commit
  25. 29 Nov, 2012 2 commits
  26. 13 Nov, 2012 1 commit
  27. 18 Oct, 2012 1 commit
    • fwu's avatar
      ARM: 7544/1: Add BUG_ON when hlt counter is wrongly used · 871df85a
      fwu authored
      1. On ARM platform, "nohlt" can be used to prevent core from idle
         process, returning immediately.
      2. There are two interfaces, exported for other modules, named
         "disable_hlt" and "enable_hlt" are used to enable/disable the
         cpuidle mechanism by increasing/decreasing "hlt_counter".
         Disable_hlt and enable_hlt are paired operation,
         when you first call disable_hlt and then enable_hlt, the
         semantics are right.
      3. There is no obvious constraint to prevent user(driver/module)
         code to prevent the case that enable_hlt is ahead of disable_hlt,
         which is a fatal operation on kernel state change from user,
         and there is no any WARNING or notification if the case happens
         in current kernel code.
         This patch aims to report BUG when the case happens, just like
         what the kernel do when enable_irq is ahead of disable_irq.
      
      Link: https://patchwork.kernel.org/patch/1527881/
      
      Signed-off-by: default avatarfwu <fwu@marvell.com>
      Signed-off-by: default avatarYiLu Mao <ylmao@marvell.com>
      Signed-off-by: default avatarNing Jiang <ning.jiang@marvell.com>
      Acked-by: Nicolas Pitre
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      871df85a
  28. 12 Oct, 2012 1 commit
  29. 01 Oct, 2012 1 commit
  30. 01 Aug, 2012 1 commit