1. 17 10月, 2014 5 次提交
  2. 30 9月, 2014 2 次提交
    • N
      ARM: 8178/1: fix set_tls for !CONFIG_KUSER_HELPERS · 9cc6d9e5
      Nathan Lynch 提交于
      Joachim Eastwood reports that commit fbfb872f "ARM: 8148/1: flush
      TLS and thumbee register state during exec" causes a boot-time crash
      on a Cortex-M4 nommu system:
      
      Freeing unused kernel memory: 68K (281e5000 - 281f6000)
      Unhandled exception: IPSR = 00000005 LR = fffffff1
      CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191
      task: 29834000 ti: 29832000 task.ti: 29832000
      PC is at flush_thread+0x2e/0x40
      LR is at flush_thread+0x21/0x40
      pc : [<2800954a>] lr : [<2800953d>] psr: 4100000b
      sp : 29833d60 ip : 00000000 fp : 00000001
      r10: 00003cf8 r9 : 29b1f000 r8 : 00000000
      r7 : 29b0bc00 r6 : 29834000 r5 : 29832000 r4 : 29832000
      r3 : ffff0ff0 r2 : 29832000 r1 : 00000000 r0 : 282121f0
      xPSR: 4100000b
      CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-rc6-00313-gd2205fa30aa7 #191
      [<2800afa5>] (unwind_backtrace) from [<2800a327>] (show_stack+0xb/0xc)
      [<2800a327>] (show_stack) from [<2800a963>] (__invalid_entry+0x4b/0x4c)
      
      The problem is that set_tls is attempting to clear the TLS location in
      the kernel-user helper page, which isn't set up on V7M.
      
      Fix this by guarding the write to the kuser helper page with
      a CONFIG_KUSER_HELPERS ifdef.
      
      Fixes: fbfb872f ARM: 8148/1: flush TLS and thumbee register state during exec
      Reported-by: NJoachim Eastwood <manabian@gmail.com>
      Tested-by: NJoachim Eastwood <manabian@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NNathan Lynch <nathan_lynch@mentor.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      9cc6d9e5
    • K
      ARM: 8177/1: cacheflush: Fix v7_exit_coherency_flush exynos build breakage on ARMv6 · ebc77251
      Krzysztof Kozlowski 提交于
      This fixes build breakage of platsmp.c if ARMv6 was chosen for compile
      time options (e.g. by building allmodconfig):
      
      $ make allmodconfig
      $ make
        CC      arch/arm/mach-exynos/platsmp.o
      /tmp/ccdQM0Eg.s: Assembler messages:
      /tmp/ccdQM0Eg.s:432: Error: selected processor does not support ARM mode `isb '
      /tmp/ccdQM0Eg.s:437: Error: selected processor does not support ARM mode `isb '
      /tmp/ccdQM0Eg.s:438: Error: selected processor does not support ARM mode `dsb '
      make[1]: *** [arch/arm/mach-exynos/platsmp.o] Error 1
      
      The error was introduced in commit "ARM: EXYNOS: Move code from
      hotplug.c to platsmp.c".  Previously code using
      v7_exit_coherency_flush() macro was built with '-march=armv7-a' flag but
      this flag dissapeared during the movement.
      
      Fix this by annotating the v7_exit_coherency_flush() asm code with
      armv7-a architecture.
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Reported-by: NMark Brown <broonie@kernel.org>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ebc77251
  3. 16 9月, 2014 1 次提交
  4. 13 9月, 2014 1 次提交
    • V
      ARM: 8137/1: fix get_user BE behavior for target variable with size of 8 bytes · d9981380
      Victor Kamensky 提交于
      e38361d0 'ARM: 8091/2: add get_user() support for 8 byte types' commit
      broke V7 BE get_user call when target var size is 64 bit, but '*ptr' size
      is 32 bit or smaller. e38361d0 changed type of __r2 from 'register
      unsigned long' to 'register typeof(x) __r2 asm("r2")' i.e before the change
      even when target variable size was 64 bit, __r2 was still 32 bit.
      But after e38361d0 commit, for target var of 64 bit size, __r2 became 64
      bit and now it should occupy 2 registers r2, and r3. The issue in BE case
      that r3 register is least significant word of __r2 and r2 register is most
      significant word of __r2. But __get_user_4 still copies result into r2 (most
      significant word of __r2). Subsequent code copies from __r2 into x, but
      for situation described it will pick up only garbage from r3 register.
      
      Special __get_user_64t_(124) functions are introduced. They are similar to
      corresponding __get_user_(124) function but result stored in r3 register
      (lsw in case of 64 bit __r2 in BE image). Those function are used by
      get_user macro in case of BE and target var size is 64bit.
      
      Also changed __get_user_lo8 name into __get_user_32t_8 to get consistent
      naming accross all cases.
      Signed-off-by: NVictor Kamensky <victor.kamensky@linaro.org>
      Suggested-by: NDaniel Thompson <daniel.thompson@linaro.org>
      Reviewed-by: NDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d9981380
  5. 12 9月, 2014 2 次提交
    • S
      xen/arm: remove mach_to_phys rbtree · d50582e0
      Stefano Stabellini 提交于
      Remove the rbtree used to keep track of machine to physical mappings:
      the frontend can grant the same page multiple times, leading to errors
      inserting or removing entries from the mach_to_phys tree.
      
      Linux only needed to know the physical address corresponding to a given
      machine address in swiotlb-xen. Now that swiotlb-xen can call the
      xen_dma_* functions passing the machine address directly, we can remove
      it.
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Tested-by: NDenis Schneider <v1ne2go@gmail.com>
      d50582e0
    • S
      xen/arm: reimplement xen_dma_unmap_page & friends · 340720be
      Stefano Stabellini 提交于
      xen_dma_unmap_page, xen_dma_sync_single_for_cpu and
      xen_dma_sync_single_for_device are currently implemented by calling into
      the corresponding generic ARM implementation of these functions. In
      order to do this, firstly the dma_addr_t handle, that on Xen is a
      machine address, needs to be translated into a physical address.  The
      operation is expensive and inaccurate, given that a single machine
      address can correspond to multiple physical addresses in one domain,
      because the same page can be granted multiple times by the frontend.
      
      To avoid this problem, we introduce a Xen specific implementation of
      xen_dma_unmap_page, xen_dma_sync_single_for_cpu and
      xen_dma_sync_single_for_device, that can operate on machine addresses
      directly.
      
      The new implementation relies on the fact that the hypervisor creates a
      second p2m mapping of any grant pages at physical address == machine
      address of the page for dom0. Therefore we can access memory at physical
      address == dma_addr_r handle and perform the cache flushing there. Some
      cache maintenance operations require a virtual address. Instead of using
      ioremap_cache, that is not safe in interrupt context, we allocate a
      per-cpu PAGE_KERNEL scratch page and we manually update the pte for it.
      
      arm64 doesn't need cache maintenance operations on unmap for now.
      Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Tested-by: NDenis Schneider <v1ne2go@gmail.com>
      340720be
  6. 27 8月, 2014 3 次提交
    • J
      ARM: 8130/1: cpuidle/cpuidle-big_little: fix reading cpu id part number · eba1c718
      Juri Lelli 提交于
      Commit af040ffc ("ARM: make it easier to check the CPU part number
      correctly") changed ARM_CPU_PART_X masks, and the way they are returned and
      checked against. Usage of read_cpuid_part_number() is now deprecated, and
      calling places updated accordingly. This actually broke cpuidle-big_little
      initialization, as bl_idle_driver_init() performs a check using an hardcoded
      mask on cpu_id.
      
      Create an interface to perform the check (that is now even easier to read).
      Define also a proper mask (ARM_CPU_PART_MASK) that makes this kind of checks
      cleaner and helps preventing bugs in the future. Update usage accordingly.
      Signed-off-by: NJuri Lelli <juri.lelli@arm.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      eba1c718
    • M
      ARM: 8129/1: errata: work around Cortex-A15 erratum 830321 using dummy strex · 2c32c65e
      Mark Rutland 提交于
      On revisions of Cortex-A15 prior to r3p3, a CLREX instruction at PL1 may
      falsely trigger a watchpoint exception, leading to potential data aborts
      during exception return and/or livelock.
      
      This patch resolves the issue in the following ways:
      
        - Replacing our uses of CLREX with a dummy STREX sequence instead (as
          we did for v6 CPUs).
      
        - Removing the clrex code from v7_exit_coherency_flush and derivatives,
          since this only exists as a minor performance improvement when
          non-cached exclusives are in use (Linux doesn't use these).
      
      Benchmarking on a variety of ARM cores revealed no measurable
      performance difference with this change applied, so the change is
      performed unconditionally and no new Kconfig entry is added.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2c32c65e
    • A
      ARM: 8127/1: module: add support for R_ARM_TARGET1 relocations · 55f0fb6a
      Andrey Ryabinin 提交于
      Kernel module build with GCOV profiling fails to load with the
      following error:
      
       $ insmod test_module.ko
         test_module: unknown relocation: 38
         insmod: can't insert 'test_module.ko': invalid module format
      
      This happens because constructor pointers in the .init_array section
      have not supported R_ARM_TARGET1 relocation type.
      
      Documentation (ELF for the ARM Architecture) says:
          "The relocation must be processed either in the same way as R_ARM_REL32 or
           as R_ARM_ABS32: a virtual platform must specify which method is used."
      
      Since kernel expects to see absolute addresses in .init_array R_ARM_TARGET1
      relocation type should be treated the same way as R_ARM_ABS32.
      Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      55f0fb6a
  7. 09 8月, 2014 2 次提交
  8. 02 8月, 2014 1 次提交
  9. 30 7月, 2014 2 次提交
    • L
      arm: Add devicetree fixup machine function · 5a12a597
      Laura Abbott 提交于
      Commit 1c2f87c2
      (ARM: 8025/1: Get rid of meminfo) dropped the upper bound on
      the number of memory banks that can be added as there was no
      technical need in the kernel. It turns out though, some bootloaders
      (specifically the arndale-octa exynos boards) may pass invalid memory
      information and rely on the kernel to not parse this data. This is a
      bug in the bootloader but we still need to work around this.
      Work around this by introducing a dt_fixup function. This function
      gets called before the flattened devicetree is scanned for memory
      and the like. In this fixup function for exynos, limit the maximum
      number of memory regions in the devicetree.
      Signed-off-by: NLaura Abbott <lauraa@codeaurora.org>
      Tested-by: NAndreas Färber <afaerber@suse.de>
      [glikely: Added a comment and fixed up function name]
      Signed-off-by: NGrant Likely <grant.likely@linaro.org>
      5a12a597
    • U
      ARM: 8113/1: remove remaining definitions of PLAT_PHYS_OFFSET from <mach/memory.h> · c6f54a9b
      Uwe Kleine-König 提交于
      The platforms selecting NEED_MACH_MEMORY_H defined the start address of
      their physical memory in the respective <mach/memory.h>. With
      ARM_PATCH_PHYS_VIRT=y (which is quite common today) this is useless
      though because the definition isn't used but determined dynamically.
      
      So remove the definitions from all <mach/memory.h> and provide the
      Kconfig symbol PHYS_OFFSET with the respective defaults in case
      ARM_PATCH_PHYS_VIRT isn't enabled.
      
      This allows to drop the dependency of PHYS_OFFSET on !NEED_MACH_MEMORY_H
      which prevents compiling an integrator nommu-kernel.
      (CONFIG_PAGE_OFFSET which has "default PHYS_OFFSET if !MMU" expanded to
      "0x" because CONFIG_PHYS_OFFSET doesn't exist as INTEGRATOR selects
      NEED_MACH_MEMORY_H.)
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c6f54a9b
  10. 24 7月, 2014 2 次提交
    • S
      ARM: 8109/1: mm: Modify pte_write and pmd_write logic for LPAE · ded94779
      Steven Capper 提交于
      For LPAE, we have the following means for encoding writable or dirty
      ptes:
                                    L_PTE_DIRTY       L_PTE_RDONLY
          !pte_dirty && !pte_write        0               1
          !pte_dirty && pte_write         0               1
          pte_dirty && !pte_write         1               1
          pte_dirty && pte_write          1               0
      
      So we can't distinguish between writeable clean ptes and read only
      ptes. This can cause problems with ptes being incorrectly flagged as
      read only when they are writeable but not dirty.
      
      This patch renumbers L_PTE_RDONLY from AP[2] to a software bit #58,
      and adds additional logic to set AP[2] whenever the pte is read only
      or not dirty. That way we can distinguish between clean writeable ptes
      and read only ptes.
      
      HugeTLB pages will use this new logic automatically.
      
      We need to add some logic to Transparent HugePages to ensure that they
      correctly interpret the revised pgprot permissions (L_PTE_RDONLY has
      moved and no longer matches PMD_SECT_AP2). In the process of revising
      THP, the names of the PMD software bits have been prefixed with L_ to
      make them easier to distinguish from their hardware bit counterparts.
      Signed-off-by: NSteve Capper <steve.capper@linaro.org>
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ded94779
    • S
      ARM: 8108/1: mm: Introduce {pte,pmd}_isset and {pte,pmd}_isclear · f2950706
      Steven Capper 提交于
      Long descriptors on ARM are 64 bits, and some pte functions such as
      pte_dirty return a bitwise-and of a flag with the pte value. If the
      flag to be tested resides in the upper 32 bits of the pte, then we run
      into the danger of the result being dropped if downcast.
      
      For example:
      	gather_stats(page, md, pte_dirty(*pte), 1);
      where pte_dirty(*pte) is downcast to an int.
      
      This patch introduces a new macro pte_isset which performs the bitwise
      and, then performs a double logical invert (where needed) to ensure
      predictable downcasting. The logical inverse pte_isclear is also
      introduced.
      
      Equivalent pmd functions for Transparent HugePages have also been
      added.
      Signed-off-by: NSteve Capper <steve.capper@linaro.org>
      Reviewed-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f2950706
  11. 18 7月, 2014 8 次提交
    • S
      ARM: 8103/1: save/restore Cortex-A9 CP15 registers on suspend/resume · ddd0c530
      Shawn Guo 提交于
      The CP15 diagnostic register holds ARM errata bits on Cortex-A9, so it
      needs to be saved/restored on suspend/resume.  Otherwise, the
      effectiveness of errata workaround gets lost together with diagnostic
      register bit across suspend/resume cycle.  And the CP15 power control
      register of Cortex-A9 shares the same problem.
      
      The patch adds a couple of Cortex-A9 specific suspend/resume functions
      to save/restore these two Cortex-A9 CP15 registers across the
      suspend/resume cycle.
      Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ddd0c530
    • W
      ARM: 8098/1: mcs lock: implement wfe-based polling for MCS locking · bf67fd31
      Will Deacon 提交于
      This patch introduces a wfe-based polling loop for spinning on contended
      MCS locks and waking up corresponding waiters when the lock is released.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      bf67fd31
    • D
      ARM: 8091/2: add get_user() support for 8 byte types · e38361d0
      Daniel Thompson 提交于
      Recent contributions, including to DRM and binder, introduce 64-bit
      values in their interfaces. A common motivation for this is to allow
      the same ABI for 32- and 64-bit userspaces (and therefore also a shared
      ABI for 32/64 hybrid userspaces). Anyhow, the developers would like to
      avoid gotchas like having to use copy_from_user().
      
      This feature is already implemented on x86-32 and the majority of other
      32-bit architectures. The current list of get_user_8 hold out
      architectures are: arm, avr32, blackfin, m32r, metag, microblaze,
      mn10300, sh.
      
      Credit:
      
          My name sits rather uneasily at the top of this patch. The v1 and
          v2 versions of the patch were written by Rob Clark and to produce v4
          I mostly copied code from Russell King and H. Peter Anvin. However I
          have mangled the patch sufficiently that *blame* is rightfully mine
          even if credit should more widely shared.
      
      Changelog:
      
      v5: updated to use the ret macro (requested by Russell King)
      v4: remove an inlined add on big endian systems (spotted by Russell King),
          used __ARMEB__ rather than BIG_ENDIAN (to match rest of file),
          cleared r3 on EFAULT during __get_user_8.
      v3: fix a couple of checkpatch issues
      v2: pass correct size to check_uaccess, and better handling of narrowing
          double word read with __get_user_xb() (Russell King's suggestion)
      v1: original
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      Signed-off-by: NDaniel Thompson <daniel.thompson@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      e38361d0
    • B
      ARM: 8097/1: unistd.h: relocate comments back to place · bc994c77
      Baruch Siach 提交于
      Commit cb8db5d4 (UAPI: (Scripted) Disintegrate arch/arm/include/asm) moved
      these syscall comments out of their context into the UAPI headers. Fix this.
      
      Fixes: cb8db5d4 ("UAPI: (Scripted) Disintegrate arch/arm/include/asm")
      Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      bc994c77
    • N
      ARM: 8070/1: Introduce arm_get_current_stack_frame() · 9865f1d4
      Nikolay Borisov 提交于
      Currently there are numerous places where "struct pt_regs" are used to
      populate "struct stackframe", however all of those location do not
      consider the situation where the kernel might be compiled in THUMB2
      mode, in which case the framepointer member of pt_regs become ARM_r7
      instead of ARM_fp (r11). Document this idiosyncracy in the
      definition of "struct stackframe"
      
      The easiest solution is to introduce a new function (in the spirit of
      https://groups.google.com/forum/#!topic/linux.kernel/dA2YuUcSpZ4)
      which would hide the complexity of initializing the stackframe struct
      from pt_regs.
      
      Also implement a macro frame_pointer(regs) that would return the correct
      register so that we can use it in cases where we just require the frame
      pointer and not a whole struct stackframe
      Signed-off-by: NNikolay Borisov <Nikolay.Borisov@arm.com>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Acked-by: NRobert Richter <rric@kernel.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      9865f1d4
    • R
      ARM: convert all "mov.* pc, reg" to "bx reg" for ARMv6+ · 6ebbf2ce
      Russell King 提交于
      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: NWill 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: NShawn 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: NRussell King <rmk+kernel@arm.linux.org.uk>
      6ebbf2ce
    • R
      ARM: make it easier to check the CPU part number correctly · af040ffc
      Russell King 提交于
      Ensure that platform maintainers check the CPU part number in the right
      manner: the CPU part number is meaningless without also checking the
      CPU implement(e|o)r (choose your preferred spelling!)  Provide an
      interface which returns both the implementer and part number together,
      and update the definitions to include the implementer.
      
      Mark the old function as being deprecated... indeed, using the old
      function with the definitions will now always evaluate as false, so
      people must update their un-merged code to the new function.  While
      this could be avoided by adding new definitions, we'd also have to
      create new names for them which would be awkward.
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      af040ffc
    • N
      ARM: 8081/1: MCPM: provide infrastructure to allow for MCPM loopback · 3721924c
      Nicolas Pitre 提交于
      The kernel already has the responsibility to handle resources such as the
      
      CCI when hotplugging CPUs, during the booting of secondary CPUs, and when
      resuming from suspend/idle.  It would be more coherent and less confusing
      if the CCI for the boot CPU (or cluster)  was also initialized by the
      kernel rather than expecting the firmware/bootloader to do it and only in
      that case. After all, the kernel has all the necessary code already and
      the bootloader shouldn't have to care at all.
      
      The CCI may be turned on only when the cache is off. Leveraging the CPU
      suspend code to loop back through the low-level MCPM entry point is all
      that is needed to properly turn on the CCI from the kernel by using the
      same code as during secondary boot.
      
      Let's provide a generic MCPM loopback function that can be invoked by
      backend initialization code to set things (CCI or similar) on the boot
      CPU just as it is done for the other CPUs.
      Signed-off-by: NNicolas Pitre <nico@linaro.org>
      Reviewed-by: NKevin Hilman <khilman@linaro.org>
      Tested-by: NKevin Hilman <khilman@linaro.org>
      Tested-by: NDoug Anderson <dianders@chromium.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3721924c
  12. 17 7月, 2014 1 次提交
    • D
      arch, locking: Ciao arch_mutex_cpu_relax() · 3a6bfbc9
      Davidlohr Bueso 提交于
      The arch_mutex_cpu_relax() function, introduced by 34b133f8, is
      hacky and ugly. It was added a few years ago to address the fact
      that common cpu_relax() calls include yielding on s390, and thus
      impact the optimistic spinning functionality of mutexes. Nowadays
      we use this function well beyond mutexes: rwsem, qrwlock, mcs and
      lockref. Since the macro that defines the call is in the mutex header,
      any users must include mutex.h and the naming is misleading as well.
      
      This patch (i) renames the call to cpu_relax_lowlatency  ("relax, but
      only if you can do it with very low latency") and (ii) defines it in
      each arch's asm/processor.h local header, just like for regular cpu_relax
      functions. On all archs, except s390, cpu_relax_lowlatency is simply cpu_relax,
      and thus we can take it out of mutex.h. While this can seem redundant,
      I believe it is a good choice as it allows us to move out arch specific
      logic from generic locking primitives and enables future(?) archs to
      transparently define it, similarly to System Z.
      Signed-off-by: NDavidlohr Bueso <davidlohr@hp.com>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Bharat Bhushan <r65777@freescale.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Chen Liqin <liqin.linux@gmail.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: David Howells <dhowells@redhat.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
      Cc: Dominik Dingel <dingel@linux.vnet.ibm.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: James E.J. Bottomley <jejb@parisc-linux.org>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Joseph Myers <joseph@codesourcery.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
      Cc: Lennox Wu <lennox.wu@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Michael Neuling <mikey@neuling.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Nicolas Pitre <nico@linaro.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Qais Yousef <qais.yousef@imgtec.com>
      Cc: Qiaowei Ren <qiaowei.ren@intel.com>
      Cc: Rafael Wysocki <rafael.j.wysocki@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Steven Rostedt <srostedt@redhat.com>
      Cc: Stratos Karafotis <stratosk@semaphore.gr>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vasily Kulikov <segoon@openwall.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com>
      Cc: Waiman Long <Waiman.Long@hp.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Wolfram Sang <wsa@the-dreams.de>
      Cc: adi-buildroot-devel@lists.sourceforge.net
      Cc: linux390@de.ibm.com
      Cc: linux-alpha@vger.kernel.org
      Cc: linux-am33-list@redhat.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-c6x-dev@linux-c6x.org
      Cc: linux-cris-kernel@axis.com
      Cc: linux-hexagon@vger.kernel.org
      Cc: linux-ia64@vger.kernel.org
      Cc: linux@lists.openrisc.net
      Cc: linux-m32r-ja@ml.linux-m32r.org
      Cc: linux-m32r@ml.linux-m32r.org
      Cc: linux-m68k@lists.linux-m68k.org
      Cc: linux-metag@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-parisc@vger.kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-s390@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Cc: linux-xtensa@linux-xtensa.org
      Cc: sparclinux@vger.kernel.org
      Link: http://lkml.kernel.org/r/1404079773.2619.4.camel@buesod1.americas.hpqcorp.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3a6bfbc9
  13. 11 7月, 2014 5 次提交
  14. 02 7月, 2014 2 次提交
  15. 01 7月, 2014 3 次提交
    • A
      ARM: 8078/1: get rid of hardcoded assumptions about kernel stack size · 9a2b51b6
      Andrey Ryabinin 提交于
      Changing kernel stack size on arm is not as simple as it should be:
      1) THREAD_SIZE macro doesn't respect PAGE_SIZE and THREAD_SIZE_ORDER
      2) stack size is hardcoded in get_thread_info macro
      
      This patch fixes it by calculating THREAD_SIZE and thread_info address
      taking into account PAGE_SIZE and THREAD_SIZE_ORDER.
      
      Now changing stack size becomes simply changing THREAD_SIZE_ORDER.
      Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      9a2b51b6
    • U
      ARM: make user_addr_max more robust · 83de911c
      Uwe Kleine-König 提交于
      With CONFIG_MMU=y get_fs() returns current_thread_info()->addr_limit
      which is initialized as USER_DS (which in turn is defined to TASK_SIZE)
      for userspace processes. At least theoretically
      current_thread_info()->addr_limit is changable by set_fs() to a
      different limit, so checking for KERNEL_DS is more robust.
      
      With !CONFIG_MMU get_fs returns KERNEL_DS. To see what the old variant
      did you'd have to find out that USER_DS == KERNEL_DS which isn't needed
      any more with the variant this patch introduces. So it's a bit easier to
      understand, too.
      
      Also if the limit was changed this limit should be returned, not
      TASK_SIZE.
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      83de911c
    • U
      ARM: nommu: don't limit TASK_SIZE · 03eca200
      Uwe Kleine-König 提交于
      With TASK_SIZE set to the maximal RAM address booting in some XIP
      configurations fails (e.g. on efm32 DK3750). The problem is that
      strncpy_from_user et al. check for the address not being above TASK_SIZE
      (since 8c56cc8b (ARM: 7449/1: use generic strnlen_user and
      strncpy_from_user functions)) and this makes booting fail if the XIP
      flash is above the RAM address space.
      
      This change is in line with blackfin, frv and m68k which also use
      0xffffffff for TASK_SIZE with !MMU.
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      03eca200